netail.net
自作フリーソフトや,ゲームに関する雑記を公開してます.
日記はソフトウェア工学の論文ネタが中心です.
最近のお知らせ (古いものはこちら)
2003-08-23 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
Exception Handling in Object Oriented SystemsECOOP2003 の Workshop の文献を消化,その2.
Johannes Siedersleben:Errors and Exceptions -- Rights and Responsibilities
概要は次の通り.
みんな例外を正しく使っていない.一番よいもので,ある種のロギングという程度で,何もしないものも多い.
コンポーネントが何をしてよいか分からない(Emergency)ときに例外を使うべきである.また,これらの例外はできるだけ早く検出するべきである.
アプリケーションエラーは,場合の数が限定されるので,動作の失敗を返すだけなら,戻り値でよい.戻り値で返せないときだけ例外を使う.また,アプリケーション関連の例外だけは直接の呼び出し主が捕まえ,外へ出してはいけない.(戻り値の一種という以上の意味を持たせてはいけない)
Emergency 例外のチェックを行わないコンポーネント群をRisk Community というかたまりで考える.ある Risk Community へは,Safety Facade という例外を吸収する Facade オブジェクトを介してアクセスする.(Facade は Emergency 例外 -- RuntimeException -- を吸収する)
事前・事後条件について,事前条件は,呼び出し側と呼び出される側とどちらが働くかの取り決めで,失敗した場合は ViolatedPreconditionException を生成すると良い.事後条件は誤った実装による戻り値から呼び出し側を守るためにあり,事前条件と役割が異なる.
例外を扱う10個のルール:
1. Emergency とアプリケーションエラーは区別する.
2. Emergency はできるだけ早く捕まえる.
3. 事前条件が違反された場合は呼び出しを失敗させる.
4. 入力パラメータは,通常は null でないと仮定する.
5. Risk Community は Safety Facade を介してアクセスされる.
6. Emergency を捕らえるのは Safety Facade に任せる.
7. Safety Facade は,事前条件違反以外のすべての例外を捕まえる.
8. アプリケーションエラーは,できるだけ戻り値で表現する.そうでない場合,Checked Exception を使う.
9. アプリケーションエラーはすぐに捕まえる.
10. 制御フローを扱うために必要でない限り,例外クラスを勝手に作らない.
_ 論文 ▲
Exception Handling in Object Oriented SystemsECOOP2003 の Workshop での論文を消化.
Ricardo Mendonca da Silva, Paulo Asterio de C. Guerra and Cecilia M. F. Rubira:"Component Integration using Composition Contracts with Exception Handling"
Computational Layer, Coordination Layer, Application Layer と三階層に分けて,Computational Layer にコンポーネントを置いて,そのサービスを Coordination Layer にあるComposition Connector が連結し,処理を行う.で,クライアントコンポーネントはApplication Layer に置かれる.
ここで,Composition Connector はComposition Contract Component を使って構成されるらしい.Contract をコンポーネントで表現してるとこが新しいのかな?と,ちょっと良く分からないが.