[#380] bug report#3 and request#5 — keiju@... (Keiju ISHITSUKA)
けいじゅ@SHLジャパンです.
1 message
1996/08/06
[ruby-list:419] Re: about exception
From:
matz@... (Yukihiro Matsumoto)
Date:
1996-08-17 14:28:12 UTC
List:
ruby-list #419
まつもと ゆきひろです.
In message "[ruby-list:418] Re: about exception"
on 96/08/14, 石塚圭樹 <keiju@shljapan.co.jp> writes:
|けいじゅ@SHLジャパンです.
|そういう状態とは, その例外を発行した関数がそれ異常処理を進められなくな
|る状態なのでしょうかね? File.open() では, ファイルを開くことができない
|という状態ですね.
そうです.
|string#index() は, 検索した結果がなかったという結果をちゃんと帰してい
|るわけですかね.
見付けた時にはoffset位置を示す整数を見付からなかった時には
nilを返しています.
|# 私自身は while gets のような一見何をやっているのか分からないのは, あ
|# まり好きではないので使ってないのですが...
そうですねえ.でも結構便利ですしねえ.
|日本語版のOSでは, 日本語を出すとかいうことはないですよね. なんか, 将来
|的には perrorもマルチリンガル対応になるような気がしますが...
むむむ.ありえないわけではないですね.やはり例外の同定の方法
を文字列以外にも用意しておく必要があるのでしょうか?
|そうですねえ. このままでは無理ですね. 松本氏がクラス変数を用いる方法を
|示していましたが, そのような方法を用いると言語のスコープ機能がそのまま
|利用できるので良いかも知れません.
なんだかそんな気がして来ました.
|# でも, クラス変数のALIASはできないんでしたっけ?
Aliasの必要がありますか? まあ,あったとしても代入すれば済
むと思いますけど.
|私が, 例外といって思うことは,
|
|失敗した例外を捕捉できる
|-> 捕捉するからには, そこから例外復帰できなければ, 例外の意味はないだ
| ろう.
|-> そのためには, どういう失敗をしたかが分からなくてはならない.
|-> だから, 例外には原因をはっきりさせる何かが必要
|-> 例外は, XXの原因で失敗する.
|
|とこんな感じになっています.
私だと
失敗した例外を捕捉できる
-> 捕捉するからには, そこから例外復帰できなければ, 例外の意味はないだ
ろう.
ここまでは共通で
-> そのためには, どういう失敗をしたかが分からなくてはならない.
-> だから, 例外には原因をはっきりさせる何かが必要
-> 例外は, XXの原因で失敗する.
と言うのはoptionalなイメージがあります.
|例外処理というと fopen() などの例外処理を思い出すので, その通りだと思
|います.
|さらに突き詰めると, 松本氏はリカバリは, 失敗したという情報(あと, 原因
|となった関数)だけで基本的にはできる. というもので, 私の場合は, 失敗し
|たという情報と原因(とその関数)があってはじめて可能になるということにな
|るのではないでしょうか?
より正確に表現すると「失敗したという情報(あと, 原因となった
関数)だけで対処できるものもあり,その割合は多い」と言うもの
です.
|file = File.open()
|
|で, 失敗したとして その後, 原因も分からずに対処しようがないというのが
|私の立場です.
これに対して言えば,原因が分からなくても対処できるものも多い
と言うのが私の立場です.
|松本氏も 同定を簡単に行なえなくてはいけないと思ってきたところで, 同定
|の方法をどうするかという問題になるのですかね?
そうですね.
同定の問題に関して認識しました.モデルの違いはあるとは言え,
いずれにしても例外の同定に関してなんらかの機能が必要であるこ
とは確かのようです.
$! を例外オブジェクト化することでなんとかできそうに思えます.
後は仕様を固めないといけませんね.
* 例外はなにによって同定されるべきか(例外オブジェクトの構造)
* 文法の変更が必要であれば,どのような変更か
* throw/interrupt/exitなど他の大域脱出との関連は?(統合する?)
* 例外発生の仕様は?
* 例外発生の C I/F は?
などについて考える必要があるでしょう.
まつもと ゆきひろ /:|)