Shiro Kawai <shiro lava.net> writes:

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

Lisp系の言語では昔から、
・例外が起きるとデフォルトではインタラクティブなデバッガループに入る。
・そのインタラクションでまた例外が起きると、再帰的に新たなデバッガルー
  プに入る。
・場合によっては、デバッガループから抜けて、例外を起こした時点から実行
  を継続できる。
という処理系が多かったと思います。

開発時に、バグで例外が起きた際、飛び込んだデバッガの中で関数定義を修正
してテスト実行を継続できるような場合もあります。

こういう使用法を想定すると、「例外ハンドラは、スタックを巻き戻してから
実行されるのではなく、例外を起こした時点で『呼び出される』(例外ハンド
ラのフレームは、それまでのスタックフレームの上に積まれる)」というのが
自然だったのだと思います。

(あるいは単に、ハードウェアの例外処理のモデルから類推して素直だったと
いうことかもしれません。)

Javaが登場した直後、comp.lang.javaの議論で、Javaの例外処理モデル(ハン
ドラに達する前にスタックを巻き戻してしまって、処理が継続できない)に対
する批判を読んだ覚えがあります。

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

「例外が起きるとスタックが深くなる」タイプの例外処理と大域脱出があれば、
「例外が起きるとスタックが巻き戻される」タイプの例外処理は実現できると
いうわけですよね。

「巻き戻される」タイプの例外処理を行なう言語の方が圧倒的に多いのは、不思
議といえば不思議な気がします。

＃ スタックオーバーフロー例外の時にスタックが深くなるのがいやだとか…?

				前田敦司

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