Exception Inference 後編

さて、で、前回の話は、「Javaのような例外システムだと、捕捉されない例外を静的にチェックできる」という話だった。（そうか？）

というか、例外を起こすかもしれない関数Aを呼んでいる関数Bは、関数Aが起こす例外を自分で処理できないのであれば、関数Aと同じように例外を投げる可能性がある、ということなんだから。その性質が、上に伝搬していくのは、当然のことで、むしろ、その情報を削ってしまって、補足されない例外をコンパイルエラーにできないほうがおかしいとも考えられる。

が、しかし、Javaの例外システムの特徴として、たいへん面倒だというのがある。

try {
	// ちょ…ちょっとsleepしたいだけなんですけど…
	thread.sleep( time )
} catch ( InterruptedException e ) {
}

てきとーなプログラマにとっては、sleepとcatch(InterruptedException e) {}はもはや、ひとつのものであり、不可分でアトミックであるといえるだろう（意味不明）

この面倒さは、実際に問題を起こしていて、たとえば、java.lang.OutOfMemoryはあまりにもあちこちで発生するので、その扱いが大変てきとーになっているというのがある。（ちゃんと捕捉してるかどうか静的にチェックできない）
つまり、Javaのような例外システムで、かつ、面倒でないものが必要だ、ということだ。
そこで、例外推論のようなものはどうだろうか、という話。

Javaは throws を書かなかった場合、「何も例外を投げない」というふうになるけど、それを、「throws を書かなかった場合は、投げる例外を自動で推論する」というふうにする。
実際、どの関数がどの例外を投げるのかは、静的に決まる…はず。（そこらへんは誰か詳しい人に聞いて…）

/* これはエラー */
void nanika1() throws ()
{
	thread.sleep( 30 );
}

/* これはふつー */
void nanika2() throws InterruptedException
{
	thread.sleep( 30 );
}

/* これは、throws InterruptedExceptionが推論される */
void nanika3()
{
	thread.sleep( 30 );
}

と、まあ、そんな感じで。（本題のほうが短い）