最近、Javaの例外について、特にチェック例外について否定論を見かけることがありました。Kent Beck、Robert C. Martin、Bluce EckelといったJava・オブジェクト指向プログラミングにおいて見識ある著名な人物がこぞって否定論を唱えています。自分的にはいまだ同意できないのですが、これだけの人物が並んで唱えると、ちょっと弱くなってチェック例外って本当に使うのが最善なのか考えてしまいます。
チェック例外について、賛成の立場で議論がないか探してみたところ、よい記事がありました。
から始まる一連の記事で、チェック例外について賛成の立場で例外設計を述べています。また、戻り値と例外についても議論があり、例外設計について考えるのによい内容です。記事に寄せられた賛否両側のコメントも理解を深めるのによい意見を表明しています。
例外の設計
- 一連の記事の中のhttp://littletutorials.com/2008/05/22/exceptional-java-design-the-failure-case-part-2/で提案している例外設計原則
API設計における例外設計原則
・カプセル化を維持せよ
・利用しやすい設計をせよ
・詳細なコンテクスト情報を提供せよ
アプリケーション側の例外処理設計原則
・障害の状況に正しく対応せよ
・例外の標準ポリシーを確立せよ
・障害後に一環した状態を提供せよ
例外を投げる原則
・バグを通知するときは非チェック例外を使え
・回復可能なドメイン特有の障害にはチェック例外を使え
例外をキャッチする原則
・必要以上に広い型(継承の上位のクラス)でキャッチしない
・finallyを使え
・フロー制御に例外を使うな
・例外を無視しない(空のcatch句を書かない)
チェック例外を良しとしない人
一連の記事の中のhttp://littletutorials.com/2008/05/06/exceptional-java-checked-exceptions-are-priceless-for-everything-else-there-is-the-the-runtimeexception/で想定しているチェック例外を良しとしないであろう人々
・一人でプログラムを作る、または少人数の優れたプログラマー同士でプログラムを作る人
・または同様のコンサルタント
・異常に陥っても大した影響をもたらさないソフトウェアを開発している人
・コンセプトの実証にのみ興味を抱くプロトタイプ作成者
・ロジックの外側に例外すべてを捌く機構を持つGUI・インタラクティブ・プログラムの作成者
・デモ用途でコンパクトにコードを紹介したい人
・初心者
これに対して、記事へのコメントに、
トランザクションシステムの開発者は障害に直面したときは、そのトランザクションから抜けるしか手がない。多くのサーバーシステムはこれに含まれる
とありました。
「.NETの例外処理」(2010/10/19追記)
.NETのエラー処理について書かれたブログがあります。Javaとのポリシーの違いも随所に書かれており、言語の違いを比較することでより深く例外設計について考えることができます。Javaプログラマーに読んでもらいたい記事です。
(2021/05/01追記)上述URLはリンク切れにつきinternet archiveのクロールURLを次に記載
Part.1は、メソッドの実行結果を分類し.NETプログラムでどう表現するかを分かりやすくかつ実践的な掘り下げでまとめられています。この記事では
よほどのことがない限り、アプリケーションでtry-catchを書いてはいけません
と語り、よほどのこと、として2つの事態
・間違って業務フローチャートから出ちゃったんだけど、元に戻って処理を続けたい
・自ら業務フローチャートの外に出て、自爆したい
を挙げています。
(2021/05/01追記)上述URLはリンク切れにつきinternet archiveのクロールURLを次に記載
.NETでは業務エラーを戻り値で表現していましたが、Javaではチェック例外を使うという対比をしています。