例外情報の極限統御：マルチレイヤーアプリにおけるStack TraceとInnerExceptionの設計思想
レガシーなVB6/VBAシステムからの移行期を経て、現在も多くの企業基幹システムを支えているVB.NET。しかし、言語仕様のモダン化や.NET Core / .NET 8への移行が進む一方で、「例外処理」に対する現場の理解は、いまだに前世紀の泥臭いレベルで停滞している。
`Try…Catch`で囲み、とりあえず`Ex.Message`をログに吐き出して握りつぶす。あるいは、スタックトレースの重要性を理解せず、UI層で握りつぶされた例外メッセージだけを見て頭を抱える。
マルチレイヤー（プレゼンテーション層、ビジネスロジック層、データアクセス層）で構成される業務アプリケーションにおいて、このエラーハンドリングの怠慢は、障害解析の時間を無駄に引き延ばし、システムの信頼性を根底から揺るがす。
今回は、シニアエンジニアおよび社内ニッチシステムの番人たちに向け、VB.NETにおける例外情報（`StackTrace` と `InnerException`）を極限まで活用し、トラブルシューティングコストをゼロに近づけるためのログ設計の真髄を授ける。
—
1. 例外の「握りつぶし」という悪習とレイヤー透過の原則
マルチレイヤーアーキテクチャの鉄則は「関心の分離」である。データアクセス層（DAO）で発生したデータベース接続エラーやタイムアウトを、そのままUI層でハンドリングすべきではない。各層は、自身の責任範囲外の異常を抽象化しつつも、「元の例外の文脈（コンテキスト）を一切損なわずに上位層へ伝播させる」義務を負う。
ここで多くの開発者が犯す最大の罪が、以下のようなコードだ。
.net
‘ 【アンチパターン】例外をキャッチしてメッセージだけを再スロー、または新規例外で上書きする
Try
‘ データアクセス処理
Catch ex As SqlException
‘ 致命的：これではスタックトレースの起点が「Throw」の行に書き換わり、真の原因が見えなくなる
Throw New Exception(“データベースエラーが発生しました: ” & ex.Message)
End Try
これでは、どこで（何行目で）本当のエラーが発生したのかという最も重要な情報（`StackTrace`）が失われる。さらに、例外の連鎖（`InnerException`）が途切れるため、DB層固有のエラーコードやステータスが失われ、根本原因へのアプローチが不可能になる。
—
2. InnerException と StackTrace の正しい継承メカニズム
VB.NET（.NET Framework / .NET Core共通）において、例外を上位層へ安全に引き渡すには、既存の例外オブジェクトをそのままスローするか、あるいは`InnerException`パラメータを持つカスタム例外や標準例外のコンストラクタを利用する必要がある。
以下のコードは、データアクセス層からビジネスロジック層、そしてプレゼンテーション層へと例外を美しく伝播させ、最終的に完璧なログを構築する実用的なパターンの実装例である。
.net
Imports System
Imports System.IO
Imports System.Runtime.CompilerServices
Namespace EnterpriseArchitecture.LoggingSample
‘ ———————————————————
‘ 1. データアクセス層 (Data Access Layer)
‘ ———————————————————
Public Class DataAccessLayer
Public Sub ExecuteQuery(query As String)
Try
‘ 擬似的な低水準例外（例：ファイル読み込みエラーやDB接続エラー）
Throw New IOException(“Disk Read Timeout: The device is not ready.”)
Catch ex As Exception
‘ 【極意】直近の例外をInnerExceptionに包み込み、文脈（Context）を付加してスロー
‘ 引数なしの Throw を使うと現在のスタックトレースを維持したまま再スローできる
Throw New DataAccessException(“データストアへのアクセスに失敗しました。”, ex)
End Try
End Sub
End Class
‘ ———————————————————
‘ 2. ビジネスロジック層 (Business Logic Layer)
‘ ———————————————————
Public Class BusinessLogicLayer
Private _dal As New DataAccessLayer()
Public Sub ProcessBusinessLogic()
Try
_dal.ExecuteQuery(“SELECT FROM CriticalTable”)
Catch ex As DataAccessException
‘ ビジネス層固有の業務例外としてラップしつつ、InnerExceptionで下位層の例外を完全に保持
Throw New BusinessLogicException(“月次集計処理の実行中に業務例外が発生しました。”, ex)
End Catch
End Sub
End Class
‘ ———————————————————
‘ 3. カスタム例外の定義
‘ ———————————————————
Public Class DataAccessException
Inherits Exception
Public Sub New(message As String, innerException As Exception)
MyBase.New(message, innerException)
End Sub
End Class
Public Class BusinessLogicException
Inherits Exception
Public Sub New(message As String, innerException As Exception)
MyBase.New(message, innerException)
End Sub
End Class
End Namespace
—
3. 究極の例外フォーマッタ：多層例外の再帰的解析ロジック
例外が適切に`InnerException`としてチェインされていても、単に `ex.ToString()` を出力するだけでは、フレームワークの内部的なノイズが多くなり、現場のオペレーターや保守エンジニアに必要な情報が埋もれてしまう。
ここで、シニアエンジニアが実装すべき「例外チェインの再帰的解析・フォーマット関数」を提示する。このコードは、スタックトレースとインナー例外の深層までを完全に掘り起こし、構造化されたログ文字列を生成する。
.net
Imports System.Text
Imports System.Reflection
Public NotInheritable Class ExceptionFormatter
Private Sub New()
‘ 静的クラスとしての設計
End Sub
”’
”’
Public Shared Function FormatDetailedException(ex As Exception) As String
Dim sb As New StringBuilder()
Dim depth As Integer = 0
Dim currentEx As Exception = ex
While currentEx IsNot Nothing
sb.AppendLine(“————————————————–“)
sb.AppendLine($”[階層 (Depth): {depth}]”)
sb.AppendLine($”例外型 (Type): {currentEx.GetType().FullName}”)
sb.AppendLine($”メッセージ (Message): {currentEx.Message}”)
‘ Win32Exception等の特殊な例外が持つネイティブエラーコード（HResultなど）の抽出
Dim hResultProp = currentEx.GetType().GetProperty(“ErrorCode”, BindingFlags.Public Or BindingFlags.Instance)
If hResultProp IsNot Nothing Then
Dim errCode = hResultProp.GetValue(currentEx)
sb.AppendLine($”エラーコード (ErrorCode): 0x{Convert.ToInt32(errCode):X8}”)
End If
sb.AppendLine(“— StackTrace —“)
If Not String.IsNullOrEmpty(currentEx.StackTrace) Then
sb.AppendLine(currentEx.StackTrace.Trim())
Else
sb.AppendLine(“(スタックトレースは利用できません)”)
End If
currentEx = currentEx.InnerException
depth += 1
End While
sb.AppendLine(“————————————————–“)
Return sb.ToString()
End Function
End Class
このコードの優位性
1. リフレクションによる固有コードの動的抽出: `SqlException` や `Win32Exception` が持つ低レベルのエラーコードを、強参照を持たずに安全に吸い出す。
2. メモリ最適化: `StringBuilder` を用いることで、ループ内での不要な文字列インスタンスの生成（ガベージコレクションへの負荷）を極限まで抑制している。
3. `AggressiveOptimization` 属性: JITコンパイラに対してこのメソッドの最適化を強く要求し、高頻度で発生するエラーログ出力時のオーバーヘッドを削ぎ落としている。
—
4. レガシー環境・Windows API連携時の例外ハンドリングの極意
業務アプリケーションがオンプレミスのWindows環境や、古いCOMオブジェクト、あるいはアンマネージドなWindows APIと連携する場合、マネージドコードの枠組みだけでは例外を捉えきれないケースが存在する。
例えば、P/Invokeを通じてネイティブDLLを呼び出す際、メモリ違反（Access Violation）やスタック破損が発生した場合、通常の `Catch ex As Exception` では捕捉できないことがある。
.net
Imports System.Runtime.InteropServices
Public Class NativeInteropHelper
‘ 例：アンマネージドDLLの呼び出し
Private Shared Function MessageBox(hWnd As IntPtr, text As String, caption As String, uType As UInt32) As Integer
End Function
Public Shared Sub SafeNativeCall()
‘ Win32 APIのエラーコードを確実に取得するためのパターン
Dim result As Integer = MessageBox(IntPtr.Zero, “テストメッセージ”, “タイトル”, 0)
If result = 0 Then
‘ APIが失敗した場合、Marshal.GetLastWin32Error() でOS側のエラーコードを取得する
Dim win32Error As Integer = Marshal.GetLastWin32Error()
‘ 独自のWin32Exceptionを生成し、適切なInnerExceptionまたはコンテキストを持たせる
Throw New System.ComponentModel.Win32Exception(win32Error, $”Windows APIの呼び出しに失敗しました。Error Code: {win32Error}”)
End If
End Sub
End Class
レガシーなシステム連携において重要なのは、「OSが吐き出したエラーコード（`Marshal.GetLastWin32Error()`）を、マネージドな例外オブジェクトのメタデータとして即座に結合すること」である。これを怠ると、イベントビューアーとアプリの独自ログを行き来する不毛なデバッグ作業に時間を奪われることになる。
—
5. チーフアーキテクトからの最終提言
例外処理とログ設計は、アプリケーションの「保険」ではない。それはシステムの内部構造を最も雄弁に語る診断計である。
- `Try…Catch` で例外を飲み込むな。
- `InnerException` を欠落させるな。
- `StackTrace` が指し示す「真の原因の発生源」を隠蔽するな。
VB.NETという言語は、その歴史の長さゆえに様々な記述方法が混在しているが、本稿で示したオブジェクトのライフサイクルと例外チェインの原則を徹底すれば、どんなに複雑なマルチレイヤー・レガシー混在システムであっても、障害解析のスピードは劇的に向上する。
妥協のないコードと設計こそが、プロフェッショナルなエンジニアリングの証である。今すぐ、自社のログ出力ルーチンを見直し、この「例外統御の思想」を実装に反映せよ。
