知識マップ: 例外処理でcatchとログはどこに置くべきか

記事「例外処理でcatchとログはどこに置くべきか」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

この記事はC#/.NETの例外処理において、例外を捕まえる境界と主ログを出す場所を分けることを提案します。一番深いhelper/utility層では広くcatchせず、Repository/Gateway層は下位実装固有の例外を意味のある失敗へ翻訳し、Application Service/UseCase層は想定内の失敗を結果化し、UI/HTTP/Job境界が失敗単位と運用文脈をそろえて主ログを1回だけ出す地点になりやすいとしています。未処理例外ハンドラは回復ポイントではなく最後の記録地点で、終了・再起動導線を整えます。各層での重複したErrorログ、throw exによるスタックトレースの喪失、OperationCanceledExceptionを障害ログとして扱うことは、いずれも原因追跡を難しくするため避けるべき対応として位置づけられています。

flowchart LR
    accTitle: 例外処理でcatchとログをどこに置くべきかの知識マップ
    accDescr: 例外を捕まえる境界・主ログ・結果化・例外の翻訳という役割を、helper層からRepository/Gateway層・UseCase層・UI/HTTP/Job境界・未処理例外ハンドラへどう配分するかを示す図
    exception_catch_boundary["例外を捕まえる境界"]
    primary_error_log["主ログ"]
    deep_broad_catch["深い層での広いcatch"]
    helper_utility_layer["helper/utility/private method層"]
    failure_unit["失敗単位"]
    diagnosis_difficulty["障害原因追跡の困難"]
    duplicate_error_logging["各層での重複ログ"]
    repository_gateway_layer["Repository/Gateway/SDKラッパー層"]
    exception_translation["例外の.NET変換"]
    limited_retry["局所的なretry"]
    usecase_layer["Application Service/UseCase層"]
    result_conversion["結果化"]
    expected_failure["想定内の失敗"]
    ui_http_job_boundary["UI/HTTP/Job/Message境界"]
    operation_canceled_exception["OperationCanceledException"]
    throw_ex_antipattern["throw ex;によるスタックトレース書き換え"]
    stack_trace_loss["スタックトレースの喪失"]
    unhandled_exception_handler["未処理例外ハンドラ"]
    process_restart_strategy["終了・再起動導線"]
    backgroundservice_unhandled_exception["BackgroundServiceの未処理例外"]
    unexpected_exception["想定外の例外"]
    deep_broad_catch -->|"用いるのは非推奨"| helper_utility_layer
    failure_unit -->|"推奨される対応"| exception_catch_boundary
    deep_broad_catch -->|"原因になり得る"| diagnosis_difficulty
    duplicate_error_logging -->|"原因になり得る"| diagnosis_difficulty
    primary_error_log -->|"防止する"| duplicate_error_logging
    repository_gateway_layer -->|"実装を担う"| exception_translation
    repository_gateway_layer -.->|"利用する"| limited_retry
    usecase_layer -->|"実装を担う"| result_conversion
    result_conversion -->|"推奨される対応"| expected_failure
    ui_http_job_boundary -->|"実装を担う"| primary_error_log
    operation_canceled_exception -->|"用いるのは非推奨"| primary_error_log
    throw_ex_antipattern -->|"原因になり得る"| stack_trace_loss
    stack_trace_loss -->|"原因になり得る"| diagnosis_difficulty
    unhandled_exception_handler -->|"実装を担う"| process_restart_strategy
    process_restart_strategy -.->|"推奨される対応"| backgroundservice_unhandled_exception
    operation_canceled_exception -->|"より先に行うべき"| unexpected_exception
    primary_error_log -->|"前提とする"| failure_unit
    usecase_layer -->|"利用する"| repository_gateway_layer
    ui_http_job_boundary -->|"利用する"| usecase_layer
    primary_error_log -->|"用いるのは非推奨"| helper_utility_layer
    primary_error_log -.->|"用いるのは非推奨"| repository_gateway_layer
    helper_utility_layer -->|"用いるのは非推奨"| exception_catch_boundary
    usecase_layer -->|"推奨される対応"| exception_catch_boundary
    ui_http_job_boundary -->|"推奨される対応"| exception_catch_boundary
    unhandled_exception_handler -->|"用いるのは非推奨"| exception_catch_boundary

概念間の関係(全25件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

深い層での広いcatchをhelper/utility/private method層に用いることは推奨されません。一番深いhelper/utility/private method層でcatch (Exception)してnull/falseを返すことは推奨されず、後始末・局所ロールバック・例外の翻訳にとどめるべきとされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
失敗単位は例外を捕まえる境界に対する本記事の推奨です。catchする場所は失敗単位を定義できる境界に寄せることが本記事の推奨で、catchできる場所ではなく責任を持って判断できる場所で受けるのが基本とされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
深い層での広いcatchは障害原因追跡の困難の原因になることがあります。深い共通関数でcatch (Exception)してnullを返すと、呼び出し元はデータが無かったのか途中で壊れたのかを区別できなくなる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
各層での重複ログは障害原因追跡の困難の原因になることがあります。Repository・Service・Controller・未処理例外ハンドラが同じ障害をそれぞれErrorやCriticalで記録すると、同じスタックトレースが何本も並び読む側が困る / 確度: 確立した関係 / 確認日: 2026-08-01 出典
主ログは各層での重複ログを防ぎます。失敗単位と運用文脈がそろう境界だけが主ログを1回出す運用にすると、各層での重複ログを防げる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Repository/Gateway/SDKラッパー層は例外の.NET変換の実装を担います。Repository/Gateway/SDKラッパー層は、HttpRequestExceptionやDBドライバ固有の例外など下位実装の都合を、その層で意味のある失敗へ翻訳する役目を担う / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Repository/Gateway/SDKラッパー層は局所的なretryを利用します。外部I/O境界では、一時的失敗と分かっている・冪等性がある・上限回数と待ち方が決まっている・失敗時の最終挙動が明確、という条件が揃うときだけ局所的なretryを行う / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
Application Service/UseCase層は結果化の実装を担います。Application Service/UseCase層は、validation不備やNotFoundなど想定内の失敗をResultや失敗DTOの形へ変える結果化を担う / 確度: 確立した関係 / 確認日: 2026-08-01 出典
結果化は想定内の失敗に対する本記事の推奨です。想定内の失敗は例外として投げ続ける必要はなく、そのユースケースの単位で結果化することが本記事の推奨 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
UI/HTTP/Job/Message境界は主ログの実装を担います。UI/HTTP/Job/Message境界は、何の操作か・誰の操作か・どのrequestかを知っているため、多くのアプリで主ログ地点になりやすい / 確度: 確立した関係 / 確認日: 2026-08-01 出典
OperationCanceledExceptionを主ログに用いることは推奨されません。利用者キャンセルやシャットダウンによるOperationCanceledExceptionを主ログ(Error)の対象として扱うことは推奨されず、制御フローの一部として扱うべきとされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
throw ex;によるスタックトレース書き換えはスタックトレースの喪失の原因になることがあります。throw ex;と書くと、その行でスタックトレースが上書きされ、本当の発生位置が失われる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
スタックトレースの喪失は障害原因追跡の困難の原因になることがあります。スタックトレースが失われると、後から本当の発生位置や原因を追えなくなる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
未処理例外ハンドラは終了・再起動導線の実装を担います。未処理例外ハンドラの主な責務は最終ログ・flush・dump採取導線に加えて、終了コードや再起動導線の整備までである / 確度: 確立した関係 / 確認日: 2026-08-01 出典
終了・再起動導線はBackgroundServiceの未処理例外に対する本記事の推奨です。BackgroundServiceの未処理例外は.NET 6以降ではログされ既定でホスト停止に寄るため、親ループで全部握りつぶすより停止して再起動戦略へ乗せるほうが安全なことがある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
OperationCanceledExceptionは想定外の例外より先に行うべきです。catch節は上から順に評価されるため、OperationCanceledExceptionをより具体的な型で先に受け、想定外例外向けの広いcatchより前に置くべきとされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
主ログは失敗単位を前提とします。主ログは失敗単位とrequestIdやuserIdのような運用文脈を伴うことが前提になる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Application Service/UseCase層はRepository/Gateway/SDKラッパー層を利用します。Application Service/UseCase層はRepository/Gateway/SDKラッパー層を呼び出し、その先で発生し翻訳された例外を受け取る / 確度: 確立した関係 / 確認日: 2026-08-01 出典
UI/HTTP/Job/Message境界はApplication Service/UseCase層を利用します。UI/Controller/Job境界はApplication Service/UseCaseを呼び出し、そこでの結果化や想定外例外を受け取って応答を決める / 確度: 確立した関係 / 確認日: 2026-08-01 出典
主ログをhelper/utility/private method層に用いることは推奨されません。helper/utility/private method層で主ログを出すことは推奨されず、この層は原則として出さない方針とされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
主ログをRepository/Gateway/SDKラッパー層に用いることは推奨されません。Repository/Gateway/SDKラッパー層で、上へ再スローするだけなら通常は主ログを出さない方針とされる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
helper/utility/private method層を例外を捕まえる境界に用いることは推奨されません。一番深いhelper/utility/private method層は、画面全体を止めるべきかなどを判断できないため、境界としてcatchするのに向かない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Application Service/UseCase層は例外を捕まえる境界に対する本記事の推奨です。Application Service/UseCase層は失敗単位を決められる境界として、想定内の失敗を結果化する適地になる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
UI/HTTP/Job/Message境界は例外を捕まえる境界に対する本記事の推奨です。UI/HTTP/Job/Message境界は、多くのアプリで想定外例外をまとめて受ける最も自然な境界になりやすい / 確度: 確立した関係 / 確認日: 2026-08-01 出典
未処理例外ハンドラを例外を捕まえる境界に用いることは推奨されません。未処理例外ハンドラは回復ポイントではなく最後の記録地点であり、回復のための境界として頼るのは推奨されない。回復戦略はその前のrequest/job境界に置くべきとされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典

主要概念の定義

例外を捕まえる境界: 画面操作1回・HTTPリクエスト1本・ジョブ1件・メッセージ1件のように、retry・結果化・継続可否を責任を持って判断できる処理の区切りで、例外をcatchすべき場所とされる境界。
主ログ: 1つの失敗に対して1回だけ出す、失敗単位と運用文脈(requestIdやuserIdなど)を伴うErrorまたはCriticalレベルの記録。
深い層での広いcatch: 一番深いhelperや共通関数でcatch (Exception)して null や false を返すなど、判断ができない場所で広く例外を受け止めてしまう書き方。
失敗単位: 画面操作1回、HTTPリクエスト1本、ジョブ1件、メッセージ1件、CSVの1行など、何が1回失敗したかを表す業務上まとまりのある処理の単位。
各層での重複ログ: 1回の障害に対してRepository・Service・Controller・未処理例外ハンドラなど複数の層が同じ例外をそれぞれErrorやCriticalとして記録してしまうこと。
Repository/Gateway/SDKラッパー層: DBドライバ、HTTP通信、ファイルI/O、vendor SDKなど下の層の実装都合が表に出る、外部I/Oを扱う境界の層。
Application Service/UseCase層: 保存処理や注文確定、CSV取り込みのようなユースケースとしてまとまりのある単位を扱い、失敗単位を決められる層。
結果化: 例外として投げ続けるのをやめて、Result型や失敗を表すDTOのような戻り値へ変え、想定内の失敗を呼び出し元が分岐で扱える形にすること。
UI/HTTP/Job/Message境界: WinForms/WPFの保存ボタン押下、ASP.NET CoreのHTTPリクエスト1本、workerのメッセージ1件のように、何の操作か・誰の操作かを知っている境界で、多くのアプリで主ログ地点になりやすい層。
OperationCanceledException: 利用者による中断やシャットダウンによって発生する例外で、制御フローの一部として扱われ、普通はErrorログの対象にしないもの。
throw ex;によるスタックトレース書き換え: 再スローの際にthrow ex;と書いてしまうことで、その行でスタックトレースが上書きされてしまう書き方。throw;を使うのが基本とされる。
スタックトレースの喪失: 本当の例外発生位置を示すスタックトレース情報が失われ、後から原因を追えなくなる状態。
未処理例外ハンドラ: AppDomain.UnhandledExceptionやWPFのDispatcherUnhandledException、WinFormsのThreadExceptionなど、回復ポイントではなく最後の記録地点となる、呼び出し階層の最終境界。
終了・再起動導線: 未処理例外ハンドラが担う、最終ログやflush・dump採取に加えて整備すべき、終了コードや再起動のための導線。
helper/utility/private method層: 文字列変換・パース・計算・内部整形のような、どの画面操作やrequestだったかを知らない、呼び出し階層の一番深い層。

機械可読データ

JSON-LD / Turtle ── この記事の知識グラフ全体
概念一覧 / 語彙(述語)の定義

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。