W です。

誤解を生みやすい表現でしたですね。失礼致しました。以下のように改めたいと
思います：

|...デフォルトの動作は Eiffel的に見れば好ましいかと思っています。(...が、）
|ここら辺(ブロックごとの rescue, 例外処理の default は例外の上位への伝播を伴う）
|を取り入れた言語とは、果たして使えるのか？というところが一番の私の関心ごとでして。

ぐらいのところです。嬉しいかどうかと言われると「今はまだ調査段階とさせて
ください」というところです。

ところで、DbC と Eiffelの例外処理デザインですが、

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

は、もう少し詳しく書いていただけるとすると、下記のどのあたりになるでしょ
うか？：

a) DbC のコンセプトには同意する。Eiffel の例外処理デザインは DbC だけと
いうことなので、
それはそれでいいだろうが、個人的には例外処理に普通のエラー処理も含めたい
ところなので、
Eiffel的例外処理は採用しない（実際 Ruby ではそうされていると思われるので
すが）。
b) DbC のコンセプトには同意するが、Eiffel の例外処理デザインには同意できない
c) DbC のコンセプトには同意できない。
d) その他

「同意できる・できない」という表現が強過ぎると思われた方は、「個人的に嬉
しいと思う・思わない」ぐらいの意味に
とっていただいてかまいません。

まつもとさんに限らず、みなさんのお考えなども参考になります。

ちなみに、W は、

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

…というところです。

// W



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