チェック例外は「悪夢」なのか？

私にとって、Java プログラミングで「その当時は名案だと思えた」一番の機能が、チェック例外と、例外に対する認識をブロードキャスト (および強制) できる機能です。けれども実際に使ってみると、コンテキストから切り離された不必要な例外処理 (および誤った処理) を強いるチェック例外は、悪夢と化します。
（"Java.next： Groovy、Scala、Clojure の共通点、第 3 回" - developerWorks）

記事の本題ではないけど、けっこう聞くはなし。「でも、それって具体的にどういうケース？」といつも思う。

たしかに例外スローはそれ自体慎重に設計すべきインターフェースの一部でありながら、「コンテクスト」や「責任」を考慮しない実装が散見されるようには思う。しかしそうではあっても、チェック例外こそはコールスタック要素のカプセル化を保証する要のように思っている。

実際、予期されている例外に対して対処をしないで済ませられるプログラムなどというものがありえるのだろうか？　そしてその「予期できる」状態というのはあくまでもコードの設計者・実装者にとってこそ確かなものであって、コードのユーザ側（呼び出し側）とっては「予期できる」かどうかは確かでない。

そのようにして「予期できない」例外のスローにプログラムのスタックを破綻させられるのはどう考えても良い事態ではない。であるならばチェック例外の宣言とその処理の強制はやはり必要なのだ、とそう考えている。