エラーハンドリング・クロニクル #nds41 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
はじめに プログラミング技術の歴史は、ありとあらゆる歴史がそうであるように、いろんな「史観」で眺めることができます。ならば、プログラミング技術の歴史を、「エラーハンドリングとの戦い」という視点から見ることもできるのではないでしょうか。本日は、エラーハンドリングとの戦いの歴史を俯瞰することで、エラーハンドリングの勘所について考えていこうと思います。 なお、このエントリはNDSという勉強会の第41回で発表した内容と同一です。 Cの時代 Cの時代のエラーハンドリングでは、関数の返り値と、グローバル変数errnoを見ることで処理が成功したか失敗したかを見るのが一般的でした。 例として、文字列をlongに変換するstrtol関数をmanで引いてみましょう。すると、だいたい以下のようなことが書かれています。 変換に失敗すると、0を返す 変換に失敗した場合、グローバルな変数であるerrnoに以下の定数を
Javaの検査例外は、呼び出し側で「どんなに注意しても防げない」異常系 - Qiita
注：本記事の内容はJavaで公式にドキュメントされているものではなく筆者の見解です。とはいえクラスを設計する上で有用な指針たり得ると思われるので公開したものです。 おさらい - 検査例外と非検査例外 Javaの例外クラスには「catchしないとコンパイルエラーになる」検査例外（チェック例外、checked exception）とそうでない非検査例外（非チェック例外、unchecked exception）があります。 検査例外は最近は嫌われる傾向がありC#では採用されていませんしAltJava言語も軒並み不採用、さらにはJavaの新しめのライブラリにも非検査例外しか投げないものが出てきていますが、適切に使えば安全なプログラミングのための強力な武器であり、検査例外の有意義さについては @irxground さんの Javaの検査例外の存在意義 をご覧ください。 例外クラスを自作する場合、検査
例外設計の話
例外設計の話。 こんな指針がいいのかなー 2013 夏 ver. 例外の目的とは？ 「例外をキャッチする主な目的は、エラーの原因を取り除いて、回復すること」 via http://dobon.net/vb/dotnet/beginner/exceptionhandling.html .NET の「例外のデザインのガイドライン」にもこう書いてある。 特定の例外が特定のコンテキストでスローされる理由を把握できている場合は、その例外をキャッチするようにしてください。 回復可能な例外だけをキャッチする必要があります。たとえば、存在しないファイルを開こうとした場合に発生する FileNotFoundException は、アプリケーションで処理できる例外です。それは、アプリケーションがユーザーに問題を知らせ、ユーザーが別のファイル名を指定したり、ファイルを作成したりできるようにすることが可能だからで
Javaプログラマが catch すんの忘れるのは計算機に探させよう
Java Pathfinder (jpf) というツールがあって、これは汎用バグ検査ツールなのです。特に、 catch し忘れた例外を、あんた忘れてはるで、と調べてくれるので簡単に紹介してみました。
エラー処理の抽象化
エラー処理の抽象化田中英行 <tanaka.hideyuki@gmail.com> 2012/06/26 @LOG.debug("nice catch!") 自己紹介田中英行 http://tanakh.jpTwitter: @tanakhGithub: https://github.com/tanakh Preferred Infrastracture 勤務のプログラマHaskellと、プログラミングについてあれこれ考えるのが好きHaskell入門書 すごいHaskellたのしく学ぼう! Learn You a Haskell for Great Good! の和訳 java-ja …！？とんでもないところに来てしまったぞ (((´･_･`))) ﾌﾞﾙﾌﾞﾙ 本日のお話なぜ、エラー処理は重要なのか？なぜ、エラー処理の抽象化は重要なのか？なぜ、エラー処理の抽象化は行われて来なかったのか？
nullを受け付けないメソッドにnullを渡した時の挙動 - 都元ダイスケ IT-PRESS
っていう話を書こうと思ってたら、以前書いてた（cf. 前提条件を破った場合、どのような挙動をするのか？ - 都元ダイスケ IT-PRESS） 上のエントリにも書いたのだが、自分はこういう時IllegalArgumentExceptionを使うようにしている。そして、commons-lang v2.6 をよく使っていたので、その中の Validate#notNull を利用してnullチェックをするのが自分のスタイルだ。 しかし、いい加減commons-lang v3系に移行しようかな、と考えて色々触っていたのだが、v3から Validate#notNull の仕様が変わり、NullPointerExceptionを投げるようになったのだ。 といった辺りの俺周辺タイムライン → Javaでnullを受け付けないメソッドにnullを渡したらどうなるべきか - Togetter で、いくつかのラ
例外の分類
元ネタは、C#チームのEric Lippert氏のブログの数年前の投稿です。 例外処理というと、「とりあえずキャッチしとけ」とか、逆に「とりあえずキャッチするな（集約例外ハンドラーで対処しろ）」とか言われたりします。かと思えば、「プロなんだから自分の頭で考えろ」とか、「業務フロー次第でしょ」などと千尋の谷に突き落とされたりもします。 極論を言えばそうなのですが、もう少しガイドラインとなるものは無いのか、ということでEricのブログの内容をかいつまんで紹介します。 Ericは、例外は4種類に分類できると言っています[1]。 例外の4分類（Eric Lippert氏による） 種類説明特徴対処方法例 致命的な例外（fatal exception） プロセスに深刻な問題が発生し、今にも死にそうな状態にある場合に発生する例外。 プログラマーの過失ではない[2]、 復旧は無理（finallyを実行する
NullPointerExceptionなどの標準例外を使っていないわけ - taediumの日記
Domaでは、Daoのメソッドに期待されない引数（nullとか）が渡された場合に例外をスローしますが、そのときの例外にNullPointerExceptionやIllegalArgumentExceptionを使っていません。代わりに、DomaNullPointerExceptionやDomaIllegalArgumentExceptionといったDoma独自の例外を投げます。 これはなぜかというと、Daoのメソッドに対する事前条件を満たしていないのか、それともDoma自身にバグあって例外がスローされてしまっているのをわかりやすくするためです。 つまり、DomaNullPointerExceptionやDomaIllegalArgumentExceptionがスローされるということは、「これはDomaが意図的にスローしています。なんらかの条件を満たしていません。」というメッセージです。そし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Application Performance Monitoring & Error Tracking Software
例外設計における大罪 - 契約
Home · Papertrail log management
ExceptionalおよびHoptoadでの拡張されたRails例外モニター