[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[jfriends-ml 1469] assertion 、事前条 件の例外スロー方法
高橋（徹）です。
「契約による設計」をキーワードにあちこちを探ってみました。
> > > ◇Ｐ９
> > > ソースコードの引数チェックにおいて、例外をthrowしているが、こ
> > > のような処理は良いものなのか、疑問があるという意見あり。
> > > (スレッドとは関係無い話ですが)
> >
> > これはEiffelとかにある「事前条件」をJavaでやってみた、ということなのでは？
> 「有無を言わせずRuntimeExceptionで落してしまうのはよくないのでは？」
> という意見です。開発時はよいのですが、運用時にRuntimeExceptionで落ちる
> のはまずいよねという内容だったと思います。
JavaReport誌1998年9月号の記事"Prevention Is Better Than A Cure"および、
JavaReport誌1999年5月号の記事"Concurrent Contracts"(双方Mike Mannion著）
において、Design by Contractについて解説されていました。
前者では、Assertionの実装例と使用例が載っています。RuntimeExceptionを
スローするかException（非RuntimeException)をスローするかについては議論が
あるようです。
後者では、CHOOSING THE RIGHT EXCEPTIONという節があり、その中で、
checked例外(catchを強制する例外）はDBCのコミュニティでは一般的ではない。
それはEiffelが強力な例外機構を持っておらず、checked例外の記述を持たない
から、とあります。ただし著者自身はchecked例外の方がDBCパラダイムにより
当てはまると述べています。
JDK1.4に追加される予定の"A Simple Assertion Facility"(JSR-041)では、
新しいキーワードassertを導入しています（なんと言語仕様に手を加える！）。
Public DraftがWebで公開されていたので眺めてみると、契約による設計について
も触れていました。Simpleさを失わないこと、過去のライブラリとの一貫性を
保つことを理由に契約による設計の事前・事後条件、不変表明機能は外したと
あります。ただし、assertを使って事後条件・クラス不変表明を実現する方法に
ついて付録に記述しています。
なお、事前条件はassertによってチェックすべきではないと述べられており、
通常のコーディングによって引数をチェックし、例外として
IllegalArgumentException等をスローすることを勧めています。
ということで、事前条件の例外にRuntimeExceptionを使うか使わないかについて
明確な指針（共通認識）はなさそうです。傾向としては、IllegalArgumentException
を使うことが多い（Sunがクラスライブラリをそう設計した？）ようです。
======------======------======
Toru Takahashi, TOSHIBA Corps. KOMUKAI Works
(office)tooru6.takahashi@xxxxxxxxxxxxx
(private)torutk@xxxxxxxxxxx
http://www.alles.or.jp/~torutk/