ポイントというか心にとまったことのアウトプットです。

※個人的な重要度のバイアスがかかっているので、「べつにいいかー」と思ってたりすることはメモしてません。

※手を動かして理解したことなど、間違いを含む可能性があります。

※手元の環境は断りがなければ基本はjava 7 をIntelliJ IDEA Ultimate on OSX で動かしてます。

「例外処理」

• メソッド宣言時に、throws Exception を書く方針について（検査例外と実行時例外）

  • 実行時例外：そのメソッドの使い方が間違っているような場合に飛ぶExceptionについては、throwsに書かない。しかるべき対応を、呼び出し側でやるべき
  • 検査例外：そのメソッドを普通に使っているのに、Exceptionが起こりうる場合は、throwsを書く
  • ↑ただし、いずれも実装者の主観によるので、実装者の一貫した実装が必要

• try-with-resource (java7)

  • リソースとはAutoCloseableインターフェースの実装オブジェクト
  • java6以前はfinallyでcloseしてた
  • catchやfinallyのまえにcloseが呼ばれる

• finally 内での例外送出は避ける

• 例外がキャッチされないと、そのスレッドが終了する（プロセスじゃない）

• 検査例外　java.lang.Exceptionを継承。必ずtry-catchが必要

• 実行時例外　java.lang.RuntimeExcetptionを継承。try-catchは任意

• メソッドのオーバーライド

  • 任意の実行時例外をオーバーライドメソッドのthrowsに加えるのはOK（検査例外は同じか下位クラスじゃないとNG）
  • オーバーライドメソッドからthrowsを削除するのはOK

• ラムダ式と例外

  • ☆検査例外を出すラムダは補足の必要あり

• assert 文

  • 原因例外
  • java -ea オブションをつけないとassert 文が有効にならない
  • -ea オブションをつけてない場合は、単に無視されるだけ
  • 一応assert は開発の時だけという方針で

int birthYear = -1;
assert birthYear > 0; // -ea オプションをつけないと意味はない

• Throwable、Exception、RuntimeExceptionは直接使わない
• 実行時例外は独自定義しない（すでにある拡張クラスを使う）
• Errorの拡張クラスを作らない
• 例外翻訳
  • 高レベルな独自定義の例外に、低レベルな原因例外をセットする
• 抑制例外
  • java7から
  • AutoClosable のclose メソッド内で発生する例外に使う

• フレームワーク例外

  • アプリ側で投げた例外を、フレームワーク側で補足する（取り決めは必要）
  • また、取り決めの例外は実行時例外にしておく（検査例外だと書くのが大変）

• 広域脱出は基本よくないけど、フレームワーク例外のような場合には有効