例外処理について、私はこう思う - K.Maebashi's はてなブログ
他人の意見の翻訳ばかりでもアレなので。 例外処理機構についての私の考え方は、Diksamがそうなっているように、 例外処理機構自体は必要 検査例外も必要 というものです。 例外処理自体の有用性について Joel Spolsky氏の記事の翻訳の感想でも書いたのですが、例外処理機構は必要だと思います。「戻り値でちまちまエラーケースを上位に戻していってうまくいくと思えるほど、私は(自分を含む)プログラマを信用していない」ためです。 Joel氏は 例外を上げるかもしれない関数を呼び、それをその場でcatchしないときはいつも、あなたは、データを整合性のない状態にしたまま突然中断された関数や、あなたが考慮しなかった別のコードの実行経路による驚くようなバグが発生する機会を作り出しているのだ。 と書いていますが、こういうケースは実際に存在します。たとえば(これは「プログラミング言語を作る」に書いた例です
Effective Java 読書会 13 日目 「Java の例外めんどくさい」 - IT戦記
IOException の catch に何を書いていいか分かりません＞＜！ はじめに 順番が前後しますが、今回は Java の特徴のひとつである例外機構についてです。 今回の範囲 223 ページ 〜 250 ページ 前回はこちら Effective Java 読書会 12 日目 「スレッド・セーフってなによ！！」 - IT戦記 Java の例外 throw 可能なオブジェクト Throwable インタフェースを実装したもの Exception を継承しない Throwable は基本的に使わない チェック例外 メソッドの実装者が「呼び出し元が回復可能」だと考えている例外 ちゃんと「なぜ、例外だったのか」理由が提供されるべき 呼び出し元は try catch で囲むか throws 宣言を書く必要がある Exception を継承していて RuntimeException を継承していな
オブジェクト指向と型システムの狭間で例外を考える - プログラマーの脳みそ
「検査例外はアジャイルやオブジェクト指向の考えに反するという事実」について一部誤解あり - じゅんいち☆かとうの技術日誌のあんまりな釣りタイトルにやれやれだぜ、と思いつつも非チェック例外多用作戦のトレードオフ認識 - 都元ダイスケ IT-PRESSでツッコミたかったことが突っ込まれてしまってるので、しょうがないのでオブジェクト指向と型システムの話でもしよう。 Javaの静的型システム ≠ オブジェクト指向 僕が10年ほど前、Javaを使い始めてからしばらくたってやっとオブジェクト指向プログラミングが掴めて楽しくなってきた頃合、これこそがオブジェクト指向なのだと誤解をしていたころ、オブジェクト指向は型がチェックできてなんぼだと思ってた。 javascriptのプロトタイプ型のオブジェクト指向に憤り、「あんなものはオブジェクト指向ではない」などと思うのがJavaプログラマ的中二病というやつだが
チェックされる例外とチェックされない例外について - じゅんいち☆かとうの技術日誌
例外の扱いについてあれこれと調べてみました。 まず、既存のエントリから。ふむふむ。ごもっとも。 Error callerによるリカバリは不能(原因はcalleeにある or 特定不能)である為。 RuntimeException リカバリの可否はcalleeに判断不能である為。callerはリカバリ可能ならばcatchすれば良いし、不可能ならばスルーすれば良い。 Exception(非RTE) 第三者異常を想定することは必須。callerにも同様の想定を強制させ、リカバリ処理を書かせなければならない為。 特にAPI設計者として、気を使うのはどういう場合にリカバリ可能とするかどうかですね。リカバリというのをどう定義するかってところ。 で、先人たちはどう例外を扱っているんだろうということで、Seasar2とかSpringを調べてみる。 Seasar2はRuntimeExceptionですね。2
エラーの種類と例外
フォルトはシステム側で発生する異常であり、アプリケーションプログラムでキャッチしても適切なリカバリ処理を行うことができません。 Errorはまさにこのために存在する例外です。 メソッドのthrows節で宣言する必要はなく、アプリケーションプログラムでキャッチすることも想定されていません。 フェイラーはアプリケーションの設計の範囲内のエラーであり、当然アプリケーションプログラム側でリカバリ処理を行える可能性があるものです。 メソッドのインタフェースはクライアントとサプライヤの間の契約であるので、発生が予想されるエラーに関してthrows節で宣言することは当然と言えるでしょう。 throws節で宣言された(RuntimeExceptionでない)Exceptionはクライアントでキャッチすることが必要になります。 デフェクトはアプリケーションのバグに起因するエラーであり、アプリケーションプログ
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
例外原理主義 - TrickDiary
「れいがい！」、「REIGAI REIGAIせよ！」、「そろそろれいがいさんへの思いを適当にまとめる」も参照のこと。 assert/エラー/例外の区別。 意味論上、本質的な違いはない。現状の実装などの都合で使い分けるもの。 問題の通知に使用される場合の signal やモナド*1等も意味論上、本質的な違いはない。 本来これらは同じような構文で記述できるべき。 assert/エラー/例外の使い分け。 なにか問題が起きた場合は基本的に例外を投げる。 リリース版ではそもそも発生することがあってはならない類の問題については assert を使用する。 パフォーマンスが問題にならない場合は assert とともに例外やエラーを併用することを推奨。 問題が起きても無視してよいものあるいは例外ではパフォーマンスや呼び出し側の実装の都合が悪い場合にはエラーする。 assert/エラー/例外の役割。 問題が
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
