ぼうメモ帳

2005-03-14 実家にて,やっとネットにつながる俺

次期グラフシミュレータ(GraphSim3)に関する考察(5)

| 次期グラフシミュレータ(GraphSim3)に関する考察(5)を含むブックマーク

5回目です.かなりだれてきました.

2回目に,問題点を挙げた.前回は,3番目の入出力データの扱いづらさについて検討した.今回は,4番目の無駄なtry{}catch{}構文と,InterruptedExceptionの記述について述べる.

  1. 不必要なコンストラクタ
  2. 入出力関数でのポート指定
  3. 入出力データの扱いづらさ
  4. 無駄なtry{}catch{}構文
  5. InterruptedExceptionの記述
  6. ステートマシンの分かりづらさ
  7. DefaultFunctionalModule

無駄なtry{}catch{}構文とInterruptedException

無駄なtry{}catch{}構文とInterruptedExceptionを含むブックマーク

GraphSimの機能回路オブジェクトは,exec関数を実装しなければならない.exec関数は,機能回路の機能記述を行う.exec関数は,繰り返し呼ばれるため,ループ記述を行う必要ない.

さて,exec関数内では,二つの例外が発生する可能性がある.ひとつは,PCAExceptionである.もう一つは,InterruptedExceptionである.

PCAExceptionは,主に,ポート名のミスなどの入出力時の例外を発生させてきた.過去形である.これは,現在のGraphSim2では,PCAExceptionは絶対に発生しないことを意味する.なぜか.いままでPCAExceptionの発生理由としていたポート名のミスなどは,明らかにプログラムバグ,エラーである.そのバグを,プログラム内で例外として補足させることはありえない.バグであれば,フレームワーク側がバグであることを通知して,そしてシミュレーションを終了させる,それが適切な挙動である考え,PCAExceptionを発生させなくした.ではなぜ,いまだにPCAExceptionが残っているのか.それは,単純に過去の遺産,なごりだけだ.はっきり言って,無駄.

では,今後PCAExceptionが活躍する場面がでてくるかどうか.それは,はっきり言って分からない.すなわち,ユーザーが例外を受け取り何らかの例外処理を記述するようなシーンがあるかどうかである.しかし,想定される例外については,ただ例外処理を記述させるよりも,例外が発生するようなシーンの統計をフレームワーク側で保存し,シミュレーション終了後に解析結果としてユーザーに示すほうが有用であると考えている.

このような理由から,次期GraphSimでは,ユーザーが補足できると言う意味でのPCAExceptionを撤廃する.

次は,InterruptedExceptionである.InterruptedExceptionは,シミュレーション実行中に,シミュレーションが強制中断された場合に呼び出される.現状では,InterruptedExceptionは,捕獲しないことを推奨している.なぜならば,この例外はフレームワーク側で捕獲するのが必然であり,ユーザー側で捕獲してもそれほどメリットはないためである.

しかし,InterruptedExceptionを見える例外としている今,うっかり捕獲してしまう場合がある.現在のGraphSim2では,InterruptedExceptionを捕まえることを前提に書かれているコードが存在する.すなわち,本来発生すべき例外を受け取れなくなってしまうことがあるということだ.これは,あまり良いことではない.

そのため,InterruptedExceptionも,見えない例外にすべきと考えている.

トラックバック - http://d.hatena.ne.jp/susumu/20050314
261067
Connection: close