ダイコン時代の設計手法 - 例外処理

例外処理は、throwする側とcatchする側に分かれますが、
最初はcatchする側について。

catch禁止。間違いない。

個々の開発者に例外をcatchさせるとろくなことにならないというのが、
私の経験則。
例外は、原則、サービス層でcatchすることなく
プレゼンテーション層に返して、プレゼンテーション層の
フレームワークに処理させた方が良いでしょう。


もちろん例外はあります。
業務ロジックを大きく分類すると

• ユースケース個別
• 共通
• データアクセス

に分かれますが、catchを禁止するのは、ユースケース個別のものです。
catchして行いたい処理は、

• ログを書く
• 再throwする
• 業務ロジックを再実行する
• 別の例外に変換してthrowする

等が考えられますが、これらはcrosscutting concernである
可能性が高い。そうAOPの登場です。
http://homepage3.nifty.com/seasar/aop.html#ThrowsInterceptor
などを使います。SpringのThrowsAdviceでは業務ロジックを再実行したりする
ことは、できませんが、大丈夫、S2のThrowsInterceptorはSpringでも
動作します。(笑)


今度は例外をthrowする側。
例外は

• 検査例外
• 実行時例外

に大きく分けられますが(Errorは除く)、よほど例外の設計に自信のない限り
実行時例外を選んだ方が良いでしょう。
検査例外は、catchを強制することも多く扱いが難しくなります。