Javaの検査例外は、呼び出し側で「どんなに注意しても防げない」異常系 - Qiita

注：本記事の内容はJavaで公式にドキュメントされているものではなく筆者の見解です。とはいえクラスを設計する上で有用な指針たり得ると思われるので公開したものです。 おさらい - 検査例外と非検査例外 Javaの例外クラスには「catchしないとコンパイルエラーになる」検査例外（チェック例外、checked exception）とそうでない非検査例外（非チェック例外、unchecked exception）があります。 検査例外は最近は嫌われる傾向がありC#では採用されていませんしAltJava言語も軒並み不採用、さらにはJavaの新しめのライブラリにも非検査例外しか投げないものが出てきていますが、適切に使えば安全なプログラミングのための強力な武器であり、検査例外の有意義さについては @irxground さんの Javaの検査例外の存在意義 をご覧ください。 例外クラスを自作する場合、検査

[xxxxxeeeee]

Haskellの戻り値と例外の関係もこれに近い気がするなぁ、検査例外がEitherやMaybeで返る型で、非検査例外が例外。

[trashtoy]

だいたい同じような内容を昔 http://d.hatena.ne.jp/daisuke-m/20081202/1228221927 で学んだ。とても分かりやすいのでオススメ

[gowithyou]

違うと思う。SQLExceptionは引数のSQLが間違えていたら、呼び出側の責任だよね？今迄の見解通り「回復可能性」で判断するのが妥当でしょ

[HHR]

チェック例外（checked exception）と非チェック例外（RuntimeExceptionとその子、unchecked exception）について

[ymsr5612]

Javaの検査例外の考え方について

[warufuzaketaichi]

Javaの検査例外が標準ライブラリであったとしても、一貫した基準を元に使われている筈だと考えるとおかしな事になるんじゃないかなぁ

[imiwon]

"検査例外とは呼び出し側の責任でない＝呼び出し側で発生を避けられない＝発生する可能性がある以上必ず捕まえる必要がある例外である"

[onefootinthegrave]

例えばだけど標準ライブラリと業務アプリでパニックになるべき状況は違う。業務アプリでのパニックは呼び出し側では捕まえてもどうしよもないから上位のフレームワークなりに任せるべき。状況で考え方かえないとダメ

[terazzo]

事前チェックの方法がわからなくてSecurityManagerのcheckPermission()で泣く泣くtry-catchした記憶が。

[Sampo]

id:gowithyou さん お返事を本文内に追記しました。