From: matz@... (Yukihiro Matsumoto)
Date: 1996-08-13T19:58:26+09:00
Subject: [ruby-list:413] Re: about exception

まつもと ゆきひろです．

このメイルも長いですが，一番大切な所には

***

というマークを置いておきました．

In message "[ruby-list:411] Re: about exception"
    on 96/08/13, Keiju ISHITSUKA <keiju@shljapan.co.jp> writes:
|
|けいじゅ＠SHLジャパンです. 

|>長いです．
|
|ながすぎます. 

石塚さんのはもっと長いという…．

|ここで示された例外に関する指針は,
|
|1. そのメソッドは通常では正しく終了する.
|2. 正しく動くことが, はっきりしていれば, 例外の記述はいらない.
|3. 異常が発生した時は, 必ず例外の対処を必要とする.
|
|というものですかね?

なんかちょっと違うような…．多分表現の問題だと思いますけど．

私の気持ちとしては

 1．例外が発生した時プログラムが中断して良ければ特別な例外処
    理は要らない(例外というのはプログラムを中断しかねない異
    常事態である)
 2．例外が発生しなければ期待した動作をしていると考えて良い
    (戻り値の検査などは必要ない)
 3．異常が発生した時に処理を継続したければ例外処理する必要が
    ある(当り前)

という感じです．

|string#index() のようなものは, (1)もはっきりしていないし, 必ずその後 
|検索位置を調べるので例外でなくて良いということですかね?

私のでいうと1で「プログラムを中断するほどの異常事態ではない」
となるので例外で無くても良いということになります．多分，同じ
ようなことを表現しているのではないでしょうか?

|># そういう意味ではEOFは例外の方が良かったかも知れない．
|
|先の条件を EOF というか EOF を発生しそうな関数(例えばgets)に当てはめる
|と, (1), (2), (3)ともに満たしますね...
|
|確かに, 今の IO#gets() の仕様は, 読み込んだ文字列を必ず nil かどうか判
|断しなくてはいけない仕様になっている... 

もう既に

  while gets

というidiomが出来ているので，いまさら変更するのにはかなり抵
抗があります．もちろん

  for line in file 

とするとすれば問題はないんですけど．今までのを全部書き換えて
回るのもちょっと大変そうだし…．

|(5) 異なる種類の例外に同じメッセージが割り当てられてしまう可能性が
|    ある.

これって全く異なる(対処法も異なる)例外に同じメッセージが割り
当てられるという意味ですよね．あまり起きないような気がするん
ですけど，楽観的すぎますかね．

|>3は他のOSに移植する時にメッセージをUNIXに合わせる方向で実装
|>することで対応できると思います．つまり例外の仕様の問題ではな
|>く，実装の問題だと思います．UNIX間ならメッセージは共通である
|>と考えて良いでしょう．
|
|統一の指針としては, それで良いと思います. ただし, エラーメッセージの辞
|書は perror などは頼らずに, ruby 内部で独自に持つ必要がでてきますね.

NT版ではね．UNIX版では統一されていると思って良いでしょう．
POSIXでも決められているみたいだし．

|>となると残りは2ですが，これもかなりの場合は文字列の分岐でな
|>んとかなりそうな気がします．もっとも前のメイルにも書いたよう
|>にいくつかの例外は「エラー」と言う例外とは別の括りにした方が
|>良いかも知れないので，これは継続して検討します．
|
|文字列の分岐で何とかなるのは, そういう例外が発生するとしてコーディング
|しているので, 思わぬ例外とはいえません. きっと, このようなケースは稀だ
|から気にしないということですよね?

「エラー」になる場合を除いてはそうだと考えています．

|(2)も(2')も問題の原因は同じようなものだと思います. (2)よりは, (2')は文
|字列で対処しやすいが, 発生の頻度は大きいというぐらいでしょうか.

|(5)の問題は, シンボル(ID)化しても解決しないのですが... クラス毎に分割
|して管理した方がよいのでは? ということを示すための問題点でした.

クラス/モジュールを横断した場合には全然問題が解決していない
んじゃないですか?

|>そのような仮定は置いていません．確かに私は，OOPには単なるク
|>ラスライブラリの利用者としての立場とクラスライブラリ作成者の
|>立場があり，両方を支援すべきだと考えていますし，その考えにし
|>たがってrubyではクラスライブラリを利用した従来型プログラミン
|>グも可能なように設計されています．
|
|も, というか. これが主だと思っているのですが... 

それはそうですね．当たりです．

|例外処理ルーチンは, 対象となる例外以外を処理すべきでないと考えます. こ
|れは, 当たり前なのですが, 言語的にもそれを行ないやすくなっている必要が
|あると感じているわけです. 

ここではたと気がつきました．

***

多分，想定している例外のモデルが違うんでしょうね．私の(現在
のrubyの)例外のモデルは，ある処理の実行が「失敗した」という
もので，付加的な情報として $! に格納されている文字列があるも
のです．

一方，石塚さんの例外は，ある処理の実行が「これこれという原因
で失敗した」というものです．

ここでモデルの優劣を論じる必要があるのかどうか分かりませんが，
すくなくとも，モデルの違いについては認識する必要があると思い
ます．

|まず,
|>  + (クラス毎などある単位で)例外種別を一元管理することの優位性
|から. 
|
|(5)で述べたように, 私が主張したいのはある単位で分割管理することです.

私の認識では5のケースはあまり起きないと思っていますし，もし
起きたとすれば分割管理では対応しきれないと思います．むしろ，
メリットがあるとすれば，5のケースではなく，例外の同定が簡単
になることでしょうね．今だと正規表現のマッチをしないと同定で
きない場合もありますからね．

|>  + (interruptなど以外で)文字列の分岐では本質的に問題がある例
|
|上記が満たされかつ, 例外識別/分岐のためのサポートがあれば, 文字列でも
|良いのかなという気もします.

前のメイルでも書いたように現在の例外メッセージは情報が埋め込
まれていますので，ちょっと分岐は難しいですね．もともと人間に
読んでもらうための情報ですから．石塚さんのモデルはもちろん，
私のモデルであっても分岐が必要となることはあるはずなので，こ
の辺はもうちょっと考えた方が良いかも知れません．

結局，両方とも例外の同定が難しいということに落ち着くのかも知
れません．私もさすがにこの問題はなんらかの手を打った方が良い
ような気がして来ました．

|確かに, これだと, 私の主張ともあっていますし, ここまであるということは
|ないのですが... さらにこれは, 従来のrescueとも互換があるわけですね.

例にあげた文法ですと，ほとんどの場合には互換があると思います．
一部修正する必要のあるプログラムもあるとは思いますが．

|>例外発生側の互換性が無いのはかなりつらいなあ．それだけのメリッ
|>トがありそうなら喜んで変えるんだけど，それほどはメリットを感
|>じていないしなあ．もっと説得してくださいよ ＞ 石塚さん
|
|まだだめ?

だめです．モデルの違いについてもっと議論しないと．

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

以前のメイルでTclの例外情報は文字列のみと書きましたが，これ
は間違いでした．人間が理解する文字列情報とプログラムが理解す
る整数のエラーコードの両方を含んでいます．