WebAPIでエラーをどう表現すべき？15のサービスを調査してみた - Qiita
2017-01-05 追記 2016年3月にエラーの標準形式RFC7807「Problem Details for HTTP APIs」が提案され、今日現在proposed standard(標準化への提唱)となっています。こちらも是非ご覧ください。 RFC 7807 - Problem Details for HTTP APIs HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様 最近はREST APIを提供しているサービスが増えてきていますね！また公開されるAPIだけでなく、Microservicesなアーキテクチャを採用して、バックエンドがWeb APIで通信するケースも増えてきているように思います。 APIを使うときはあまり気にしたこともなかったですが、いざAPIを設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
雑貨's tumblr - エラーと例外のハンドリング
source: Error and Exception Handling Table of Contents 1 参考文献 2 ガイドライン 2.1 例外をいつ使うべきか？ 2.2 どのように例外クラスを設計すべきか？ 2.3 プログラマのエラーとは何か？ 2.4 どのように例外をハンドリングすべきか？ 2.4.1 catch(…)はできるだけ使わない 1 参考文献 以下の文献は汎用かつ堅牢なコンポーネントを記述する際の入門としていいだろう。 D. Abrahams: “Exception Safety in Generic Components” これはもともと M. Jazayeri, R. Loos, D. Musser (eds.): Generic Programming, Proc. of a Dagstuhl Seminar, Lecture Notes on
例外について色々と考えてみた - ぐるぐる～
オブジェクト倶楽部、コーディング規約の会の「C# コーディング標準」の駄目なところ - ぐるぐる〜から派生して、 「他の例外クラスを継承しただけの例外クラスを作らない」に不同意の理由 - Diary of Dary、 例外クラスの指針 - 猫とC#について書くmatarilloの雑記や、さらには Twitter で Java の検査例外と非検査例外についての議論へと発展したので例外についてまじめに考えてみた。 あくまで、今の自分の考えなので真に受けない方がいいかも！そもそも経験が少ないので、トンチンカンなことを言ってるかもしれません。 あ、それと、用語は基本的に Java から取ってきています。ただ、メソッドじゃなくて関数を使っているけど、これに深い意味はありません。多分。 例外とは まず、例外とは一体何者なのか、ということ。 ここでは面倒を避けるために、Meyer 先生の定義を借りること
Throwableについて本気出して考えてみた - 都元ダイスケ IT-PRESS
Throwable、Exception、RuntimeException(RTE)、Errorあたりを整理しながら、色々考えてみた。私見に基づくので、間違っているかもしれないけれど、自分としては頭が整理できたかな、と感じたので晒してみる。異論があったらコメントください。 まず、一番基礎的なところで、継承関係の整理から。こんなツリーになっています。 Throwable Error Exception RuntimeException そして、本稿での用語の定義。caller＝呼出す側のコード callee＝呼出される側（throwする側）のコードとします。 Throwable Throwableは「throw文に指定できる何か」という意味ですね。 Instances of two subclasses, Error and Exception, are conventionally used
Xerial Wiki: Exception
例外 Java Tutorials: http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html 例外の構文 try, catch, finally Javaでは、プログラムの実行中にエラーが起こったときに、例外クラス(Throwableインターフェースを実装したもの)を投げる(throw)ことがあります。例外がthrowされると、プログラムの流れがとまり、try文中なら、その外側のcatchクローズによって例外が補足されます。 tryブロック中を正常に終了したときも、例外処理を行った後も、finallyクローズ内のコードは必ず１度実行されます。特に必要としない場合は、finally節を省略してもよいです。 try { // throws IOExceptionという宣言をもつメソッドを実行 }
イヌネコ - d.y.d.
03:14 08/08/31 LLFuture 行ってきました。まとめ記事は何百人も書いてそうなので、以下、これにかこつけて自分語りをする。 ☆ Larry Wall の基調講演。ひたすら Parser の話をしてて素晴らしかった。 ☆ 100年の言語…は、 Ypsilon の藤田さんが、エラーメッセージのわかりやすさについて考えてますか？という問いかけを されてたのが印象に残っています。個人的に この頃 から気になってるんですけども、 言語内DSL のようなものを作ること＆そのDSLが正常動作するときに 裏でホスト言語で何が起きているかをまったく気にしなくていいようにすることは簡単でも、 そのDSLがそのDSLのシンタックスや静的セマンティクスとして間違っているときに適切なエラーを 出せるようにするのは非常に面倒、という感覚があります。ホスト言語の意味でのエラーを 出されてもユーザ側とし
菊池 Blog - 今週のクラス System.Exception
目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 386 記事 - 16 コメント - 576 トラックバック - 104 ニュース BlogRollするぐらいならトラックバックしてこい。 記事のカテゴリ .NET Framework オブジェクト指向 プログラミング全般 過去の記事 2008年9月 (3) 2008年8月 (1) 2008年7月 (1) 2008年6月 (3) 2008年5月 (2) 2008年4月 (1) 2008年3月 (1) 2008年2月 (20) 2008年1月 (8) 2007年12月 (16) 2007年11月 (2) 2007年9月 (3) 2007年8月 (1) 2007年7月 (5) 2007年6月 (1) 2007年5月 (
それが例外なのかどうかを判断するのはクライアント側ではないのか、という - <s>gnarl,</s>技術メモ”’<marquee><textarea>￥
http://www.kmonos.net/wlog/88.html#_2233080818を見て思いついた話(ぬるぽとは関係ないけど、Integer.valueOf的な処理のエラー処理の別アプローチとして。) エラーを返すか例外を返すか。 「例外」かどうかを決めるのは誰なのか、という。 辞書にキーがあることをユーザが確信しているかの問題。確信してたら例外だしないかもと思ってたらnullが返ってほしい。 「例外を投げる」インタフェースと「失敗という値を返す」インタフェースを、すべての「ユーザが失敗を予期できる」処理に対して用意する方法。 例外は例外的な状況で使うべしという原則を徹底すると、catchすべき例外はほとんど設計ミス？少なくとも、parseIntの例外をキャッチしてフォーマットエラー補足なんてのはひどい。 tryブロックに一行しか書いてないのは特におかしい。 ソリューション。 「
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
例外設計における大罪 - 契約
http://ml.tietew.jp/cppll/cppll/article/13601
IBM Developer