【スーパーまとめ】メソッドのエラー処理を考える 高橋徹

　Java でのエラー処理の方法についてまとめます。出典は、WEB + DB PRESS vol.51 「巧いメソッド設計　第六章　メソッドのエラー処理を考える」です。

【対象】

• 言語は Java
• 「契約による設計」を採用した場合の実装方法

【そもそもエラーとは】

• A の条件の元、B という処理を行い、C という条件になったとする。
• この時、以下のものをエラーとする。
1. A の条件が不正だった時は、B の呼び出し元のメソッドのバグによるエラー
2. C の条件が不正だった時は、B のメソッドのバグによるエラー

【エラーの通知方法】

• 上記の様なエラーは、事前条件（A）チェック、および事後条件チェック（C）により検出ができるが、その通知方法は大まかに下記の３通りである。
1. 戻り値による通知
• true/false や int などなどで返す事が考えられるが、メソッド本来の戻り値との切り分けが難しい
2. 例外による通知
• B 自体のバグの場合、チェック例外（Exception のサブクラス）にしても呼び出し元が対処できる訳ではないので非チェック例外（RuntimeException のサブクラス）とする
• 例外に使用するクラスの使用基準があいまいである
• 非チェック例外の場合、ドキュメントに明記しておかないと例外仕様が不明瞭になってしまう
3. アサーションによる通知
• 事前、事後のチェックを行い、エラーがあった場合には assert 文で通知する
• 記述が若干少なく、楽である
• 例外の型の問題はなく、コメントを付ければ例外仕様は分かりやすいという点において、例外による通知よりも使いやすい
• リリース時にオフにした場合、何も把握できなくなってしまう
• パッケージ、クラス単位でアサーションのオン / オフを指定する事ができるので、パフォーマンスが問題になるならそれを利用するという手も

プログラムの出荷時に表明（アサーション）をオフにすることは、綱渡りの練習を一度うまくやり終えただけで本番の綱渡りに挑戦するようなものです。ドラマチックな価値はありますが、生命保険は下りないでしょう。 

※まとめ注：要するに出荷時にアサーションを一概にオフにする事はオススメしないと言っている 

【事前条件チェックの注意点】

1. 呼び出し側が条件の成立を判定できない条件を事前条件に含めてはならない。例えば、下記の様なものである。
1. 外部からアクセスできない変数の値
2. 処理を開始しないと判定できない事項
3. そもそもプログラムで判定できない事項
2. 下記の様なものは、「プログラム外部の異常」なので事前条件チェックには含めない
1. DB と正しく接続できる事
2. ハードディスクや RAM に十分な空きがある事
3. ファイルが読み出し可能である事