墜落を許すな：VB.NETにおける「最終防衛ライン」の構築とクラッシュレス化の極意
VBAの泥沼から這い上がり、VB.NETの荒波を渡ってきた諸君へ。
システム開発において、最も恥ずべきは「理由も分からず、黒い画面のまま沈黙するアプリケーション」だ。特にオンプレミスで稼働するレガシーな業務システムにおいて、未処理例外による強制終了は、単なるバグではない。それは信頼の喪失であり、保守コストの爆発を意味する。
今日は、アプリケーションが死の淵に立った時、いかにして尊厳を保ち、その死に様（ダンプ）を記録し、ユーザーに謝罪を残すか。`AppDomain.UnhandledException`を用いた、プロフェッショナルのための「最終防衛ライン」を伝授する。
—
1. 例外の階層を理解せよ：なぜ通常のTry-Catchでは不十分なのか
多くのジュニアエンジニアは、すべての処理を `Try…Catch` で囲めば安全だと錯覚している。だが、それは幻想だ。
非同期処理のデリゲート内、スレッドプール内、あるいはP/InvokeによるWindows API呼び出しの深部で発生する致命的な例外は、スコープを突き抜けてプロセスそのものを破壊する。
プロセスの生存権を握るのは、スレッドではなく`AppDomain`だ。ここが沈めば、すべてが終わる。だからこそ、我々は「グローバルハンドラ」を設置し、プロセスの崩壊を検知しなければならない。
—
2. 最終防衛ラインの実装：AppDomain.CurrentDomain.UnhandledException
以下の実装は、アプリケーションのメインエントリポイント（`Sub Main`や`Application_Startup`）で実行せよ。ここで重要なのは、「例外を握りつぶしてアプリを継続させる」という安易な妥協をしないことだ。致命的エラーにおいて重要なのは、安全な終了（Graceful Shutdown）と、事後解析のためのフォレンジックデータの確保である。
Imports System
Imports System.IO
Imports System.Diagnostics
Public Module GlobalExceptionHandler
”’
”’
Public Sub Initialize()
‘ AppDomainレベルの例外をキャッチするイベントを登録
AddHandler AppDomain.CurrentDomain.UnhandledException, AddressOf CurrentDomain_UnhandledException
End Sub
Private Sub CurrentDomain_UnhandledException(sender As Object, e As UnhandledExceptionEventArgs)
Dim ex As Exception = DirectCast(e.ExceptionObject, Exception)
‘ 1. 緊急ログの書き出し（FileIOのオーバーヘッドを避けるため最小限に）
LogFatalError(ex)
‘ 2. メモリダンプの取得（可能であればMiniDumpWriteDump等をAPI経由で呼ぶ）
‘ ※ここでは擬似的な通知処理を記述
MessageBox.Show(“システムに致命的なエラーが発生しました。” & vbCrLf &
“担当者に連絡してください。” & vbCrLf &
“ID: ” & Guid.NewGuid().ToString(),
“緊急シャットダウン”, MessageBoxButtons.OK, MessageBoxIcon.Error)
‘ 3. 資源の明示的解放は行わず、即座にプロセスを終了させるのが安全
‘ 不整合な状態のオブジェクトを弄り回すのは、さらなる地獄を招く
Environment.Exit(1)
End Sub
Private Sub LogFatalError(ex As Exception)
Dim logPath As String = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, “fatal_error.log”)
Dim logContent As String = $”[{DateTime.Now}] FATAL: {ex.Message}{vbCrLf}{ex.StackTrace}”
File.AppendAllText(logPath, logContent)
End Sub
End Module
—
3. レガシー環境とWindows API：メモリ最適化の真実
VB.NETを使い続ける現場には、往々にして「アンマネージドなCOMオブジェクト」や「Windows API」との混在が存在する。これらが引き起こすメモリリークやアクセシビリティ違反は、`UnhandledException`を誘発する最大の要因だ。
- Marshal.ReleaseComObjectの呪い:
COMオブジェクトを解放する際、`Marshal.ReleaseComObject`を使うのは当然だが、依存関係にあるオブジェクトを解放順序を誤ると、例外以上にタチの悪い「ゾンビプロセス」が残る。`Finally`ブロックでの解放を徹底せよ。
- P/Invokeのスタック保護:
API呼び出し時のデータ型変換（`String`から`LPCSTR`など）は、CLRのマーシャラに任せるな。構造体のサイズを固定し、`StructLayout(LayoutKind.Sequential)`を明示的に指定すること。ここが曖昧だと、メモリ領域の破壊が発生し、例外すら吐かずにプロセスが消滅する。
—
4. 伝説的アーキテクトからの忠告
「クラッシュレス」とは、エラーを隠蔽することではない。
エラーを「正しく検知し、正しく記録し、正しく敗北する」ことだ。
もし諸君のシステムが、未処理例外で「何が起きたか不明なまま」落ちるなら、それはエンジニアとして敗北だ。今回実装した`UnhandledException`ハンドラは、いわば「ブラックボックス」だ。飛行機が墜落しても、原因を特定できれば次は墜落しない。
システムに完璧を求めるな。だが、システムが死ぬ瞬間には、必ず「遺書」を残させよ。
それが、数多のシステムと対峙してきた者たちの、最低限の矜持である。
