http://blogs.borland.com/abauer/archive/2006/11/03.aspx
2006年11月03日
try...finally

ここ数日、例外に関して多少の混乱があることを示すようないくつかの興味深
いコメントがありました。より明確にはtry...finally構文です。"try...finaly"
の使用に関して、私を立ち止まらせ、なぜそのようにするのか不思議に思うよ
うな、いくつかのかなり興味深いねじれがあるようでした。例外を伴なうプロ
グラミングでは、ほとんど全ての場所でいきなり制御が離れた場所に移される
ということを常に意識していなければなりません。色々な意味で、マルチスレッ
ドのシナリオでどうするのかと非常に似た問題についてアプローチし、考える
必要があります。どちらの場合でも、潜在的な2つ(あるいはマルチスレッドで
はそれ以上)のコードの通過経路を常に意識のうちに留めておく必要があります。
一つは簡単で、プログラムの全体的なロジックと意図を定義するコード中の文
をあなたが書いている順番です。もう一つの、しばしば忘れられているコード
経路は、例外が実行される経路です。

例外がライズされた(C++や類似の言語の用語では"投げられた")とき、その動作
の背後では多くの隠された作業が行われています。プラットフォームや言語に
依存する傾向があるため、実際に何が行われているのかの詳細には立ち入るつ
もりはありません。プログラマの視点から何が起きているのかや具体的な
"try...finally"構文について焦点を合わせていきます。"try...finally"ブロッ
クについて考える一つの方法は、第2のコード実行経路で"邪魔をされる"という
プログラマのやり方です。しかしそこでは通常のコード実行経路で"邪魔をされ
る"ことから特異です。全体的な見地では、例外を使用するプログラミングにお
いて"try...finally"ブロックは最も多く使用される(そしてしばしば誤用され
る)ブロックの形式です。典型的なアプリケーションにおける"try...finally"
ブロックと"try...exception"ブロックの比率は100:1のオーダであるとしてお
きましょう。しかしなぜそれを使い、なにがよいのでしょう？リソース管理の