手作りネットプロトコル工房コミュの正しい例外の扱い方【草稿】

1. 全ての例外は、捕捉した後で復帰できるなら復帰、復帰できないならそのまま外部に波及させて中断するという方針以外にない。それは Checked / Unchecked に関わらない。 Unchecked Exception というのは単に自動的に波及する例外でしかない。

2. クリーンアップ処理では例外を送出してはいけない。 JFCの close() release() その他のメソッドが既に throws IOException であるという事が問題を複雑にしている。本来、これらのメソッドは、たとえそのリソースが開かれていなかったとしても、close()処理を成功裏に完了しなければいけない。

3. 例外を送出してもいいのは処理を中断する必要がある場合のみだ。

4. 本来複数の例外を同時に送出する機能があるべきだが、それは許されていない。

　　void start(){
　　　　a=create();
　　　　b=create();
　　　　a.start();
　　　　b.start();
　　}

　　void stop() {
　　　　a.stop();
　　　　b.stop();
　　}

このとき、a.stop() が正常に終了しないと b.stop()メソッドは実行されない。結果、 stop()メソッドを呼びだした結果としてオブジェクトが不正な望ましくない状態になってしまうため問題がある。これを避けるようにコーディングすると、例外が同時に２つ以上報告される状態になる可能性がある。

　　Throwable tt=null;
　　try {
　　　　a.stop();
　　} catch ( Throwable t ) {
　　　　tt=t;
　　}
　　try {
　　　　b.stop();
　　} catch ( Throwable t ) {
　　　　tt=t;
　　}
　　if ( tt != null ) throw t; // ??

これはJavaの機能上の制約から不可能である。

止められないというのは、つまりUSBメモリ上のデータを操作していたら、子供が来てUSBメモリを引っこ抜いてしまった、という状態と似ている。これは物理的な障害であってプログラムからの操作では絶対に復帰できない。このような場合、プログラムからはどのような対応をとる事が出来るのだろうか。

⇒

これは集約オブジェクトは内部とは別物ということではないだろうか。つまり、内部にいくつかのソケットを持っている。 open()メソッドでこれらを順番に開いていくが、途中でIOExceptionが発生した。これはつまり、外部から見れば、内部の事情は知らないがopen()メソッドが正しく終了しなかったという事を表しており、つまりは IOExceptionを外部に波及してはいけないということを表しているのではないだろうか。このような場合では集約されたオブジェクトは内部で抱えているオブジェクトの如何によらず、そのopen()という処理が失敗したという事のみを外部に知らせなければいけない。

◇

補足： Exception の型を分ける時

... これは発生した例外を区別して処理する必要があるときである。区別して処理する必要がなければ Exceptionの型を分ける必要は無い。