泥沼の「原因不明エラー」に終止符を打て：VB.NETマルチレイヤー開発における例外伝播の極意
開発現場でこんな絶望を味わったことはないだろうか。
「画面層で `Exception: データベース処理でエラーが発生しました` とキャッチされたが、実際の原因がSQLの構文ミスなのか、コネクションタイムアウトなのか、はたまた一意制約違反なのか、ログを見ても全くわからない」
マルチレイヤーアーキテクチャ（プレゼンテーション層、ビジネスロジック層、データアクセス層）を採用する業務システムにおいて、例外処理の設計を誤ると、デバッグ地獄が幕を開ける。
特にVB.NETの現場では、古いVB6時代の名残を引きずった `On Error Resume Next` のような悪習や、安易な `Catch ex As Exception` による例外の握りつぶしが、保守性を劇的に低下させている。
今回は、VB.NETでの `InnerException` と `StackTrace` を完全に手なずけ、「どこで何が起き、なぜそれが起きたのか」を1秒で特定できる堅牢なエラー追跡メカニズムを構築する極意を伝授する。
—
1. なぜ「安易なキャッチ」がシステムを腐らせるのか
多くのプログラマブルな初学者は、エラーハンドリングと聞くととりあえず次のようなコードを書きがちな傾向にある。
‘ 【アンチパターン】絶対にやってはいけない例外の握りつぶし
Try
‘ データベース処理
Call DataAccessMethod()
Catch ex As Exception
‘ ログに吐いておしまい、あるいは無視
Console.WriteLine(“エラーが発生しました: ” & ex.Message)
End Try
これの何が問題か。
データアクセス層（DAL）で発生した「SQL Serverへの接続断」という致命的な例外が、ビジネスロジック層（BLL）、そしてプレゼンテーション層（UI）へと伝播する過程で、ただの「一般的なエラー」にすり替わってしまう。
上位層へ例外を投げる際は、「元の例外を隠蔽せず、コンテキスト（文脈）を付加してラップする」のがマルチレイヤー設計の鉄則である。ここで主役となるのが `InnerException` だ。
—
2. InnerException と StackTrace のメカニズム
.NETの `Exception` クラスは、例外チェーン（Exception Chaining）を構築するための強力なプロパティを持っている。
- `Message`: その層で定義されたエラーメッセージ。
- `StackTrace`: 現在の例外がスローされた位置のスタックトレース。
- `InnerException`: この例外を引き起こした「真の原因（直前の下位層の例外オブジェクト）」。
上位層で新しい例外を生成する際、コンストラクタの引数に下位層の `ex` を渡すことで、例外の「DNA鑑定」が可能になる。
‘ 正しいラップの概念
Try
‘ 下位層の処理
Call _repository.UpdateData()
Catch dalEx As SqlException
‘ ビジネス上の意味を持つ例外に包み直す（InnerExceptionに元凶を保持させる）
Throw New BusinessLogicException(“顧客データの更新に失敗しました。”, dalEx)
End Try
この設計により、ログ出力機構では最上位のメッセージだけでなく、`InnerException` を再帰的に辿ることで、「UI層のメッセージ」→「BLL層のエラー」→「DAL層のSQLエラーと正確な行番号」のすべてを完全にトレースできるようになる。
—
3. 【実務対応】プロダクションコードで実装する堅牢な例外追跡基盤
ここからは、実際の業務システム（ファイル入出力やデータベース連携を想定）で即座に使える、洗練されたモジュール構造を示す。
ステップ1: カスタム例外の定義
業務エラーとシステムエラーを明確に分離するため、カスタム例外を定義する。
Namespace Exceptions
‘ アプリケーション独自の基底例外
Public Class AppLayerException
Inherits Exception
Public Sub New(message As String)
MyBase.New(message)
End Sub
Public Sub New(message As String, innerException As Exception)
MyBase.New(message, innerException)
End Sub
End Class
‘ データアクセス層専用の例外
Public Class DataAccessException
Inherits AppLayerException
Public Sub New(message As String, innerException As Exception)
MyBase.New(message, innerException)
End Sub
End Class
End Namespace
ステップ2: 各レイヤーでの例外伝播実装
データアクセス層、ビジネスロジック層、プレゼンテーション層の連携モデルを見てみよう。
Imports System.IO
Imports YourNamespace.Exceptions
Namespace Layers
‘ ==========================================
‘ 1. データアクセス層 (DAL)
‘ ==========================================
Public Class CustomerRepository
Public Sub SaveCustomerData(filePath As String, data As String)
Try
‘ 意図的にファイル書き込みエラーを誘発（存在しないパス等）
File.WriteAllText(filePath, data)
Catch ex As IOException
‘ DAL固有の例外としてラップして上位へスロー
‘ ※ここで元の ex を InnerException に渡すことが絶対条件
Throw New DataAccessException($”ファイルアクセスに失敗しました: {filePath}”, ex)
Catch ex As Exception
‘ 予期せぬ例外のフォールバック
Throw New DataAccessException(“データ層で予期せぬ致命的エラーが発生しました。”, ex)
End Try
End Sub
End Class
‘ ==========================================
‘ 2. ビジネスロジック層 (BLL)
‘ ==========================================
Public Class CustomerService
Private ReadOnly _repository As New CustomerRepository()
Public Sub RegisterCustomer(id As Integer, name As String)
Dim targetPath As String = $”C:\Data\Customer_{id}.txt”
Dim fileContent As String = $”ID:{id}, Name:{name}, Date:{DateTime.Now}”
Try
‘ DALを呼び出す
_repository.SaveCustomerData(targetPath, fileContent)
Catch dalEx As DataAccessException
‘ BLLとしてのコンテキスト（文脈）を付加して再スロー
‘ 例外の連鎖（InnerException Chain）がここで維持される
Throw New AppLayerException($”顧客ID: {id} の登録処理中に業務エラーが発生しました。”, dalEx)
End Try
End Sub
End Class
‘ ==========================================
‘ 3. プレゼンテーション層 (UI / エントリーポイント)
‘ ==========================================
Public Class MainForm
Private ReadOnly _service As New CustomerService()
Private Sub btnSave_Click(sender As Object, e As EventArgs) Handles btnSave.Click
Try
‘ 処理実行
_service.RegisterCustomer(101, “Taro Yamada”)
MessageBox.Show(“登録が完了しました。”, “成功”, MessageBoxButtons.OK, MessageBoxIcon.Information)
Catch ex As Exception
‘ ★ここが極意：再帰的に例外を解析して完全なログを出力する
Dim detailedLog As String = ExceptionUtility.GetDeepStackTrace(ex)
‘ 実際の現場ではここでNLogやlog4netなどのロガーに出力する
System.Diagnostics.Trace.Error(detailedLog)
‘ ユーザーには優しく、かつ的確なメッセージを表示
MessageBox.Show(ex.Message, “システムエラー”, MessageBoxButtons.OK, MessageBoxIcon.Error)
End Try
End Sub
End Class
End Namespace
—
4. すべての元凶を暴き出す！「例外解析ユーティリティ」の極意
スタックトレースとインナー例外を美しく結合し、ログファイルへ一網打尽に出力するためのユーティリティクラスの決定版を共有する。
このコードを共通ライブラリに持たせておくだけで、バグ調査の効率が桁違いに向上する。
Imports System.Text
Namespace Exceptions
Public NotInheritable Class ExceptionUtility
Private Sub New()
‘ 静止クラス
End Sub
”’
”’
Public Shared Function GetDeepStackTrace(ex As Exception) As String
Dim sb As New StringBuilder()
Dim depth As Integer = 0
Dim currentEx As Exception = ex
sb.AppendLine(“========== EXCEPTION REPORT START ==========”)
While currentEx IsNot Nothing
sb.AppendLine($”— [階層: {depth}] —————————————-“)
sb.AppendLine($”例外型: {currentEx.GetType().FullName}”)
sb.AppendLine($”メッセージ: {currentEx.Message}”)
sb.AppendLine($”ソース: {If(currentEx.Source, “N/A”)}”)
sb.AppendLine(“— スタックトレース —“)
sb.AppendLine(If(currentEx.StackTrace, “スタックトレース情報はありません。”))
sb.AppendLine()
currentEx = currentEx.InnerException
depth += 1
End While
sb.AppendLine(“========== EXCEPTION REPORT END ============”)
Return sb.ToString()
End Function
End Class
End Namespace
このユーティリティが吐き出すログの美しさ
上記のコードでキャッチされた例外を `GetDeepStackTrace` に通すと、ログには以下のような鮮明な履歴が残る。
========== EXCEPTION REPORT START ==========
— [階層: 0] —————————————-
例外型: YourNamespace.Exceptions.AppLayerException
メッセージ: 顧客ID: 101 の登録処理中に業務エラーが発生しました。
ソース: YourNamespace
— スタックトレース —
場所 YourNamespace.Layers.CustomerService.RegisterCustomer(Int32 id, String name)
— [階層: 1] —————————————-
例外型: YourNamespace.Exceptions.DataAccessException
メッセージ: ファイルアクセスに失敗しました: C:\Data\Customer_101.txt
ソース: YourNamespace
— スタックトレース —
場所 YourNamespace.Layers.CustomerRepository.SaveCustomerData(String filePath, String data)
— [階層: 2] —————————————-
例外型: System.IO.DirectoryNotFoundException
メッセージ: パス ‘C:\Data\Customer_101.txt’ の一部が見つかりませんでした。
ソース: mscorlib
— スタックトレース —
場所 System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
場所 System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, AccessRights rights, …
========== EXCEPTION REPORT END ===========
「どの層で、どんな業務コンテキストの時にエラーが起き、最終的にどのシステム的要因（この場合はディレクトリが存在しないこと）が原因で崩壊したのか」が一目瞭然である。これ以上のデバッグ資料が必要だろうか？
—
5. アーキテクトからの提言：ファイル・DB連携時の注意点
業務システムの自動化ツールやバックグラウンドバッチをVB.NETで構築する際、ファイルやデータベースのIO処理は例外の温床になりやすい。以下の3点を必ずコードレビューのチェックリストに加えてほしい。
1. リソースの確実な解放 (`Using` ステートメント)
`StreamReader` や `SqlConnection`, `SqlCommand` などのアンマネージリソースを内包するオブジェクトは、例外発生時でも確実に破棄されるよう、必ず `Using` 構文（VB.NETの `Using … End Using`）を使用すること。リソースリークが連鎖的な例外を引き起こす主因になる。
2. ログ出力自体の例外対策
エラーログをファイルやDBに書き込む処理そのものが、ディスク容量不足などで例外を吐くことがある。ロギング処理の中では絶対に例外を外へ漏らさない（最悪の場合は `Trace.WriteLine` やイベントビューアへのフォールバックに留める）こと。
3. 生（生体）の例外メッセージをエンドユーザーに見せない
SQLの構文や接続文字列、内部の物理パス（例: `C:\inetpub\wwwroot\…`）がユーザー画面に露出することは、セキュリティ上の致命傷（情報漏洩）となる。ユーザーには抽象化された安全なメッセージを表示し、詳細な `InnerException` と `StackTrace` は厳重に管理されたログファイルにのみ封じ込めること。
—
最後に
「動けばいいや」というコードは、開発者自身の首を数ヶ月後に絞めることの裏返しに他ならない。
マルチレイヤーアプリケーションにおける例外設計は、単なるエラー対策ではなく、システムの健康状態を監視し、障害発生時に迷わず外科手術を行うための「羅針盤」である。
VB.NETの持つ強力なオブジェクト指向機能と例外チェーンを正しく理解し、明日の保守現場を笑顔にする堅牢なコードを書き上げてほしい。
