「小さいエラー」をたくさん踏んだほうがいい - インターネットの備忘録
管理職の仕事って、「わたしがカバーできる範囲内でならどんどんミスっていいよ、って部下に任せて、何かあったら粛々と責任を取っていくことだよね」みたいな話をしました。 仕事の権限委譲って重要で、何かあったら責任は取るからやってみて、って思い切れない人が管理職につくと、チームが硬直してしまうし、業務もスタックしてしまう。そして、ミスでしか得られない知見もあるはずなので、必ずしもミス＝悪ではない、という前提をもって任せる。そういう腹のくくり方が管理職には必要で、その覚悟を引き受けるから権限をもらえたり、お金をたくさんもらえたりするんだよね、という感じ。 という覚悟を持って仕事を渡しているので、メンバーには「こっからここの範囲内なら、いろいろトライしてみていいよ」と言って任せられたら、じゃんじゃん挑戦してミスってみてほしいなと思っているんですが、なかなかそうもいかないようです。 たとえば、経験が浅い
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
Cのエラーハンドリングと例外設計、例外処理のメモ - 百日半狂乱
二十五日半狂乱、6日目(の分...orz)の記事 Cのエラーハンドリングを毎回やるのは面倒だ！ 前回も言ったが、Cではエラーハンドリングに戻り値とerrnoを用いる． それはそうと例外設計において"無視"は大罪である． だから、関数を呼び出したら戻り値は漏らさずチェックすべきだ． ということで、例えば以下のように逐一戻り値をチェックする． if(send(sockfd, buf, len, 0) < 0){ ERROR("send"); exit(1); } あぁ、面倒だ． 一体コードのどの部分が正常系の処理なのか？ ほとんどエラーハンドリング*1で埋め尽くされるじゃないか． そもそもエラーハンドリング部分に書くのは毎回同じコードだし、コードの繰り返しは防ぎたい． エラー処理部分をラッピングして楽をする unpv12eの中でラッパーを被せることによってこの面倒を回避する方法を知った． in
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
