【Haskell学習｜実務向け】実務で差がつく！例外を「意味のある文字列」に変換する設計術

導入

開発現場において、例外が発生した際にそのままスタックトレースをログに出力したり、ユーザーに表示したりしていませんか？これはセキュリティ上のリスクがあるだけでなく、ユーザー体験を著しく損なう原因にもなります。本記事では、例外オブジェクトを適切な形式に変換する「表示用メソッド」の設計方法を解説します。

基礎知識

プログラミングにおける例外（Exception）は、本来プログラムの異常終了を防ぎ、適切にハンドリングするための仕組みです。しかし、言語標準の toString() や printStackTrace() は、開発者向けのデバッグ情報が主目的であり、エンドユーザーには難解です。実務では、これらを「ユーザー向けの親切なメッセージ」と「エンジニア向けの詳細なログ情報」に分離して扱う必要があります。

実装/解決策

解決策は「表示ロジックの分離」です。例外をそのまま扱うのではなく、displayException のような変換用メソッドを定義し、呼び出し元で利用するようにします。これにより、ビジネスロジックと表示形式を切り離し、将来的なフォーマット変更にも柔軟に対応できるようになります。

サンプルプログラム

以下の例は、Scalaを用いた実装です。パターンマッチを活用し、例外の種類に応じてユーザーに伝えるべきメッセージを制御する手法を示しています。

// ユーザーに表示すべき情報の定義 object ExceptionFormatter {


  // 例外を人間が読みやすい形式に変換するメソッド

  def displayException(e: Throwable): String = {

    e match {

      // 特定の業務例外の場合は詳細を表示

      case ex: IllegalArgumentException =>

        s"入力内容に不備があります: ${ex.getMessage}"

      // データベース関連の例外は、ユーザーには詳細を伏せて汎用メッセージを返す

      case _: java.sql.SQLException =>

        "現在システムが混雑しています。後ほど再度お試しください。"

      // 未知の例外は、ログIDを表示して問い合わせを促す

      case _ =>

        s"予期せぬエラーが発生しました。管理者へ連絡してください。 (ErrorID: ${System.currentTimeMillis()})"

    }

  }

}

// 実行例 val error = new java.sql.SQLException("Connection Timeout") println(ExceptionFormatter.displayException(error)) // 出力: 現在システムが混雑しています。後ほど再度お試しください。

応用・注意点

実装にあたっては、以下の3点に注意してください。

1. ログの出力先を分ける
ユーザーに表示するメッセージは簡潔にすべきですが、開発者が調査するための「スタックトレース」や「入力データ」は、必ず別のログファイルに記録しておく必要があります。

2. セキュリティの考慮
スタックトレースをそのまま画面に出すと、ライブラリのバージョンやディレクトリ構造などが露呈し、攻撃のヒントを与える可能性があります。必ず「隠すべき情報」と「出すべき情報」を分離してください。

3. 多言語対応（i18n）
実務では、メッセージを直接コードに書くのではなく、リソースファイルから読み込むように設計すると、将来的な国際化対応がスムーズになります。

適切な例外変換は、ユーザーの不安を軽減し、運用コストを下げるための重要な一歩です。ぜひ今日から取り入れてみてください。