まつもと ゆきひろです

In message "Re: [langsmith:154] Re: 例外処理:Eiffel とRuby"
    on Wed, 13 Oct 2004 00:00:02 +0900, W <ttn3w7u2fs mx6.ttcn.ne.jp> writes:

|>「(Eiffelのように例外はDbCだけに使うというのでない限り) 嬉しい理由は見当たらない」です。

|は、もう少し詳しく書いていただけるとすると、下記のどのあたりになるでしょ
|うか？：
|
|a) DbC のコンセプトには同意する。Eiffel の例外処理デザインは DbC だけと
|いうことなので、
|それはそれでいいだろうが、個人的には例外処理に普通のエラー処理も含めたい
|ところなので、
|Eiffel的例外処理は採用しない（実際 Ruby ではそうされていると思われるので
|すが）。

これですね。DbCについては、有効なコンセプトかもしれないが、
万能ではないし、言語そのものをDbC流に設計するほどではないと
思っている。というか、DbCのために他のエラー処理が面倒になる
んだったら本末転倒ではないかと。

個人的には通常の例外処理の範囲内でDbCを行った方が良いと思っ
てます。統一的に扱えるし。上に伝搬したい時に明示的に行う必要
はありますが、頻度を考えるとむしろメリットに思えます。

|ちなみに、W は、
|DbC のコンセプトには同意できる。Eiffel の例外処理デザインも半分同意でき
|る。しかし、ルーチンにしかハンドラが書けない点、ステータスコードは補助的
|な扱いである点、素のままでは原始的対処法（OOSC1 邦訳 p.210 の
|quasi_inverse がその典型例）しかない書けないのは何か変。ライブラリ
|（EXCEPTIONSクラス）で ignore を提供するのもしっくり来ない。エラー処理全
|般に、結局 if文などによるステータスチェック方式と例外処理との両方が必要
|なのもいまいち納得できな2い。何か上手い方法でもないだろうか。
|
|…というところです。

本当にDbCラブな人が言語をデザインするなら、DbCによる「表明の
不成立」と通常の「例外」の両方を用意するのかもしれません( 使
いやすいかどうかは不明)。もっとも、その場合、例外が発生した
ということは契約として見た時にどうなのか、という問いに応えを
用意する必要があるでしょうが。

                                まつもと ゆきひろ /:|)

--
ML: langsmith quickml.atdot.net
使い方: http://www.atdot.net/~ko1/quickml