1. 導入：なぜエラーの統一が重要なのか
大規模なプロジェクトでは、利用する複数のライブラリがそれぞれ独自の例外型を定義していることが一般的です。これらをそのまま放置すると、呼び出し元で無数の例外をキャッチし分ける必要があり、コードは複雑化し、変更に弱くなります。本稿では、異なる例外を一つの「基盤エラー型」へ集約し、保守性の高いエラーハンドリングを実現する方法を解説します。
2. 基礎知識：型による抽象化とラップ
関数型プログラミングの視点では、例外を単なる「副作用」として扱うのではなく、型として扱います。異なる例外を一つの型に統合する手法として、「アップキャスト（上位型への変換）」と、「変換（ラップ）」という考え方が重要です。ライブラリ特有の例外を、自前で定義したドメイン固有の例外型で包み込むことで、呼び出し元は詳細な実装を知ることなくエラーを処理できるようになります。
3. 実装と解決策
解決策はシンプルです。各ライブラリの境界線で「変換関数」を通し、アプリケーション共通の「基盤エラー型」に変換します。これにより、ビジネスロジック層は「何が起きたか」というドメイン上の意味に集中できます。
4. サンプルプログラム
以下のコードは、外部ライブラリの例外をアプリケーション独自のエラー型に変換する例です。
// アプリケーション固有の基盤エラー型
sealed class AppError {
data class NetworkError(val message: String) : AppError()
data class DatabaseError(val message: String) : AppError()
data class UnknownError(val cause: Throwable) : AppError()
}
// 外部ライブラリの例外（仮定）
class LibraryAException(val code: Int) : Exception()
// ライブラリのエラーをアプリのエラーに変換する関数
fun handleLibraryError(e: Throwable): AppError {
return when (e) {
is LibraryAException -> AppError.NetworkError(“通信エラーが発生しました: コード ${e.code}”)
else -> AppError.UnknownError(e)
}
}
fun main() {
try {
// ライブラリの呼び出しを想定
throw LibraryAException(404)
} catch (e: Exception) {
// エラーを基盤型にラップして集約する
val appError = handleLibraryError(e)
// 呼び出し元は AppError のみを意識すればよい
when (appError) {
is AppError.NetworkError -> println(“通知: ${appError.message}”)
is AppError.DatabaseError -> println(“ログ記録: ${appError.message}”)
is AppError.UnknownError -> println(“予期せぬエラー: ${appError.cause}”)
}
}
}
5. 応用・注意点
この手法を用いる際の注意点は、「元の例外情報を捨てないこと」です。ラップする際は、必ず元の例外（cause）を保持してください。デバッグ時にスタックトレースが追えなくなると、かえって調査コストが増大します。また、型クラスを利用して「エラーを変換可能にする」インターフェースを定義しておくと、将来新しいライブラリを追加する際にも、修正範囲を最小限に抑えることが可能です。大規模プロジェクトでは、この「境界での変換」を徹底することが、堅牢なシステムを作る鍵となります。
コメント