例外処理のデザインは難しいものだと思います。書きやすさ、効率、
セマンティクスの一貫性の3拍子を揃えるのがなかなかかなわない。
Schemeコミュニティでもそこで何を重視するかでいつも議論が平行線に
なるようです。

From: Fumisky Wells <ttn3w7u2fs mx6.ttcn.ne.jp>
Subject: [langsmith:138] Re: 例外処理:Eiffel とRuby
Date: Thu, 7 Oct 2004 11:29:28 +0900

> さて、例外処理の実装として、
> 
> 1) エラーコード(やメッセージやエラーオブジェクト)を伴うか否か
> 2) rescue句(Java/C++系 では catch ブロック)の最後で呼び出し側に伝搬するか否か
> 3) retryできるか否か
> 4) 任意の文やブロックで rescue句(Java/C++系 try-catch)が書けるか
> 5) 構文的に美しいか(かなり主観入っています。櫛形文法か try{}catch{}か
>    という意味だとご理解下さい)
> 
> というあたりで分類してみると、

Scheme(srfi-18 *1)ですと、こんな感じですかね。
1) - yes  任意のオブジェクトを例外ハンドラに渡すことが可能。
2) - no
3) - no   但し例外ハンドラから例外発生地点に戻れる。
4) - yes
5) - n/a  Lisperはあまり構文を気にしないので。

srfi-18の「例外」は他の例外機構を実装するための一番基礎になる
機構を定めているため、たぶん他の多くの言語の例外機構とは異なり、
例外ハンドラ(rescue節)の継続が例外発生時点の継続になっています。
つまり、例外ハンドラを素直に終了すると、例外を投げる関数(raise)
から戻ります。Eiffel/Rubyのretryは副作用前提でないとあまり
意味がないので、これは関数的なretryの実現と言えるかも
しれません。

Schemeにはもうひとつ、高レベルの例外処理マクロguardを定めた
srfi-34があり、それはRubyやJava/C++系のセマンティクス
(例外ハンドラを素直に終了すると例外処理のブロックを終えたことに
なる)を実現しています。

*1: srfi-* : Schemeのライブラリ仕様みたいなもの。

--shiro





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