例外を検知する側
RuntimeExceptionにラップして返す。
検査例外を非検査例外(RuntimeException)にラップして返します。とりあえずこれだけ覚えておけば最低限無難なコードになります。(e.printStackTrace();などで最低限出力してあるコードよりは)
|
1 2 3 4 5 6 7 |
try { ファイル処理など // 正常系 ... } catch (IOException e) { throw new RuntimeException(e); } |
なお、より適切な非検査例外にラップして返せるとなお良い。上の例で言えば、「UncheckedIOException」にラップして送出するのが適切です。
- IllegalArgumentException(与えられたパラメータが想定外の場合)
- IllegalStateException(呼び出された側の内部状態が想定外の場合)
アンチパターン
自前でロギングしてから再送出する。
|
1 2 3 4 5 6 |
try { ファイル処理 } catch (IOException e) { log.warn("xxxx " + e, e); // 自前でログを出力するのはNG throw new UncheckedIOException(e); } |
これをすると、自前のログが出力された後、大域の例外ハンドラで再度同じようなログが出力されてしまう。これをすると運用時に二箇所別の原因でエラーが出ているものだと勘違いしてしまう。
非検査例外にラップし忘れる。
|
1 2 3 4 5 |
try { ファイル処理 } catch (IOException e) { throw new UncheckedIOException("オリジナルメッセージ"); } |
これをすると、元の例外の原因の情報が損なわれてしまう。必ずエラーオブジェクトを非検査例外にラップすること。
try-with-resources構文を使う。(Java7以降）
|
1 2 3 4 5 |
try (ファイル処理) { ファイル処理 } catch (IOException e) { throw new UncheckedIOException(e); } |
finallyでファイルの後処理を記述すると、その中でもtry-catchをしなければならず冗長な記述になってしまう。Javaの環境が新しめであれば、「try-with-resources」を使った方が良いです。
例外を受信する側
基本的な指針としては個々に記述することなく大域で例外クラスを処理するようにすると良いです。
アプリの最上位層(mainメソッドなど)でtry-catchを書く
シンプルでわかりやすいです。ただ、現実はあまり使われるケースは少ないです。
mainメソッドからスクラッチで開発するケースは少ないですし、Webアプリにしてもフレームワークにもっと良い大体手段があるためです。
Webフレームワークの例外処理機構を利用する。
普通のWebフレームワークなら例外クラスに応じた例外ハンドラを実行する機構を持ってます。Spring MVCなら例外ハンドラクラスや、例外メソッドに対してアノテーションで例外クラスを指定します。
DIコンテナのInterceptor機構を利用する。
DIコンテナの管理下にあるクラスの任意のメソッド呼び出しに対して前後処理を組み込めます。
この記事へのコメントはありません。