例外の握りつぶし — catchして何もしない

try で囲んで、catch は空。あるいはエラーを受け取って、そのまま何事もなかったように先へ進む。動いているように見えて、実は最悪のデバッグ地獄への入り口です。

横にスクロール

症状：どう気づくか

• 空の catch ブロック（catch (e) {}）や、except: pass がある。
• 「たまに動かない」「原因が分からない」不具合が報告されるが、ログに何も残っていない。
• エラーをログに出しているが、出すだけで処理は続行しており、後段でおかしくなる。

try {
    config = loadConfig(path);
} catch (IOException e) {
    // 握りつぶし：configはnullのまま先へ進む
}
config.get("port");   // ← ここで NullPointerException（真の原因はloadConfigの失敗）

なぜ悪いのか

例外は「ここで想定外のことが起きた」という報告です。それを握りつぶすと、報告そのものが消えます。

最も厄介なのは、症状が発生源から離れた場所に、遅れて現れることです。上の例では、本当の原因は「設定ファイルの読み込み失敗」なのに、実際にプログラムが落ちるのは、はるか後段で null を触った瞬間。スタックトレースは後段を指すので、そこを何時間調べても真因にはたどり着きません。さらに悪いケースでは、落ちすらせず間違った結果を静かに出し続ける（保存したつもりのデータが消えている、など）。

直し方

捕まえたら、必ず次の3つのどれかをする。

try {
    config = loadConfig(path);
} catch (IOException e) {
    // 再送出：原因を保持したまま、文脈を足して上へ
    throw new ConfigException("設定の読み込みに失敗: " + path, e);
}

肝心なのは、元の例外（原因）を捨てないこと。ラップして投げ直すときも、元例外を cause として渡せば、スタックトレースが根本までつながります。

まとめ

• 例外の握りつぶしは、catch した後に何もしないこと。エラーが起きた事実が消える。
• 最悪なのは、症状が発生源から離れて遅れて現れること。null が後段で落ちたり、静かに誤った結果を出し続けたりして、真因にたどれない。
• 捕まえたら必ず記録・再送出・回復のどれかをする。再送出時は原因例外を保持してトレースをつなぐ。
• 意図的な無視は、なぜ無視してよいかをコメントで説明できるときだけ。空 catch とは区別する。