想定外例外で終了すべきか継続すべきかの判断表

日英シート付きの Excel チェックリストをダウンロード

このファイルは Checklist-ja と Checklist-en の 2 シート構成で、この記事の判断軸を 継続条件 / 終了条件 / 実装方針 / 判断順 の 4 カテゴリ 27 項目に分解したものです。Status と Notes 列は空のままなので、障害対応の記録や設計レビューのチェック表としてそのまま使えます。

想定していない例外の話になると、つい「落とすか、catch して続けるか」の二択で考えがちです。 ただ、実務ではこの二択の置き方が少し乱暴です。

本当に見たいのは、壊れた可能性がある範囲を閉じ込められるか です。

• その操作だけ失敗で終えられるのか
• その画面 / 接続 / ワーカーだけ再初期化すればよいのか
• もうプロセス全体の整合性が怪しいのか

この順で見ると、かなり整理しやすくなります。

この記事では、C# / .NET の Windows アプリ、常駐アプリ、Windows サービス、装置連携ツールなどを前提に、想定していない例外が起きたときに継続してよい条件と、終了したほうがよい条件を判断表としてまとめます。

1. まず結論

• catch (Exception) で握りつぶして続行、はだいたい危険です。
• 継続してよいのは、失敗した単位を捨てられる、共有状態を元に戻せる、外部副作用を説明できる、の 3 つが揃うときです。
• UI の 1 操作、1 件の入力、1 件のジョブなど、処理境界が明確なら継続できることがあります。
• 逆に、共有の書き換え可能な状態、常駐ループ、メインスレッド、起動処理、ネイティブ境界、メモリ破壊臭が絡むなら終了寄りです。
• StackOverflowException、AccessViolationException、OutOfMemoryException のような「プロセス全体の健全性」を疑う例外は、継続前提で考えないほうが安全です。
• WPF や Windows Forms には未処理例外を拾って見かけ上続ける道もありますが、続けられることと続けて安全なことは別です。
• 長時間動くサービスや監視アプリは、半分壊れたまま生き延びるより、落ちて再起動されたほうが診断もしやすく安全なことが多いです。

要するに、判断の軸は 不変条件を回復できるか です。

1.1 この記事で使う言葉

判断表を読む前に、繰り返し出てくる 5 語だけ先に決めておきます。

この記事の知識マップ

想定外の例外への対応は、catch (Exception)で握りつぶして処理を継続することではなく、共有状態の不変条件と失敗単位、外部副作用を説明できるかどうかで継続か終了かを判断すべきだと整理する記事です。StackOverflowExceptionやAccessViolationException、深刻なOutOfMemoryExceptionのようにメモリ破壊の兆候を伴う例外や、COM・P/Invokeなどネイティブ境界の異常は終了寄りで、Environment.FailFastやEnvironment.Exitが終了の実装手段になります。BackgroundServiceの親ループが想定外例外で落ちた場合は、Windowsサービスとして動かす限りEnvironment.Exitで終了コードを返さないと回復操作が働かず、AppDomain.UnhandledExceptionなどの未処理例外ハンドラーは記録に使うべきで状態の回復手段ではないことも扱います。

flowchart LR
    accTitle: 想定外の例外を継続すべきか終了すべきかの知識マップ
    accDescr: 想定外の例外に対する継続と終了の判断が不変条件・失敗単位・外部副作用の確認を前提とすること、メモリ破壊が疑われる例外やネイティブ境界の異常が終了寄りであること、BackgroundServiceの想定外例外時にはEnvironment.Exitでの終了コードがWindowsサービスの回復操作に必要なこと、未処理例外ハンドラーは回復ではなく記録に使うべきであることを示す図
    unexpected_exception["想定外の例外"]
    invariant["不変条件"]
    continue_processing["処理の継続"]
    failure_unit["失敗単位"]
    external_side_effect["外部副作用"]
    catch_exception_antipattern["catch (Exception)での握りつぶし"]
    zombie_process["ゾンビ化"]
    terminate_process["プロセスの終了"]
    stackoverflowexception["StackOverflowException"]
    accessviolationexception["AccessViolationException"]
    environment_failfast["Environment.FailFast"]
    outofmemoryexception["OutOfMemoryException"]
    memory_corruption_symptom["メモリ破壊の兆候"]
    environment_exit["Environment.Exit"]
    native_interop_boundary["ネイティブ境界"]
    backgroundservice["BackgroundService"]
    stopapplication["IHostApplicationLifetime.StopApplication"]
    windows_service["Windowsサービス"]
    unhandled_exception_handler["未処理例外ハンドラ"]
    exception_recovery_attempt["例外後の状態回復の試み"]
    continue_processing -->|"前提とする"| invariant
    continue_processing -->|"前提とする"| failure_unit
    continue_processing -->|"前提とする"| external_side_effect
    catch_exception_antipattern -.->|"原因になり得る"| zombie_process
    catch_exception_antipattern -->|"用いるのは非推奨"| unexpected_exception
    terminate_process -->|"推奨される対応"| stackoverflowexception
    terminate_process -->|"推奨される対応"| accessviolationexception
    environment_failfast -->|"推奨される対応"| outofmemoryexception
    accessviolationexception -.->|"原因になり得る"| memory_corruption_symptom
    environment_failfast -->|"推奨される対応"| memory_corruption_symptom
    environment_failfast -->|"実装を担う"| terminate_process
    environment_exit -->|"実装を担う"| terminate_process
    native_interop_boundary -.->|"原因になり得る"| memory_corruption_symptom
    terminate_process -.->|"推奨される対応"| native_interop_boundary
    backgroundservice -.->|"前提とする"| environment_exit
    stopapplication -.->|"用いるのは非推奨"| windows_service
    backgroundservice -->|"実装を担う"| windows_service
    unhandled_exception_handler -->|"用いるのは非推奨"| exception_recovery_attempt
    catch_exception_antipattern -.->|"両立しない"| backgroundservice
    environment_failfast -.->|"防止する"| external_side_effect
    unexpected_exception -->|"で確認できる"| unhandled_exception_handler

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全21件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. この記事でいう「想定していない例外」

2.1 想定内と想定外を分ける

まず、珍しい例外と想定外の例外は同じではありません。

たとえば、こういうものは頻度が低くても 想定内にできます。

• ユーザーが存在しないファイルを選んだ
• 通信先が一時的にタイムアウトした
• 取り込み CSV の 1 行が壊れていた
• キャンセル操作で OperationCanceledException が出た
• 業務ルール違反でその処理だけ失敗にしたい

これらは、その失敗をどう扱うかを設計で先に決められる種類です。

一方で、この記事で主に扱う 想定していない例外は、こういうものです。

• 自分のコードの前提が崩れて NullReferenceException や InvalidOperationException が出た
• 共有状態の更新途中で例外が飛び、どこまで反映されたか怪しい
• 監視ループやメッセージ処理の親ループが落ちた
• COM / P/Invoke / vendor SDK 境界で異常が出た
• AccessViolationException や StackOverflowException のように、そもそもプロセスの健康診断が赤い

つまり、「この例外が起きたあとに、アプリの状態をまだ信用してよいか分からない」ものです。

2.2 二択に見えて本当は三択ある

この話をややこしくする犯人は、継続を 1 種類で考えてしまうことです。

実務では、だいたい 3 段階に分かれます。

「アプリを継続する」と言っても、何もなかった顔でそのまま続けるのと、壊れた部分を切り離して継続するのでは重みが違います。

3. まず見る判断表

3.1 全体像

まずはこの表から見ると、だいたいの方針が決まります。

flowchart TD
    A["想定していない例外"] --> B{"メモリ破壊 / スタック枯渇 / 致命的な資源枯渇の臭い?"}
    B -- "はい" --> Z["終了 / FailFast / 再起動"]
    B -- "いいえ" --> C{"失敗した単位を捨てられる?"}
    C -- "いいえ" --> Y["終了寄り"]
    C -- "はい" --> D{"共有状態をロールバック / 再初期化できる?"}
    D -- "いいえ" --> X["サブシステム停止 or 終了"]
    D -- "はい" --> E{"外部副作用を説明できる?"}
    E -- "いいえ" --> X
    E -- "はい" --> W["その操作だけ失敗として継続"]

図の最初の分岐にある「メモリ破壊の臭い」は 3.4 で、右上の FailFast は 9.7 で具体的に扱います。

3.2 例外型より先に見ること

例外型だけで即決しないほうがよいです。 先に確認したいのは、このあたりです。

3.3 危険度の高い例外

細かい例外型の話を全部する必要はありませんが、継続前提で見ないほうがよいものはあります。

3.4 「メモリ破壊の臭い」「ゾンビ化」は何を見て言うのか

この 2 つは感覚的な言葉に見えますが、実際に見ているものは決まっています。

まず、メモリ破壊を疑う症状です。

0xc0000005 は STATUS_ACCESS_VIOLATION、0xc0000374 は STATUS_HEAP_CORRUPTION で、いずれも Microsoft の NTSTATUS 一覧に定義されている値です。特にヒープ破損は、壊した瞬間ではなく 壊れたヒープを次に触った側 で落ちるため、落ちた場所が犯人とは限りません。この形の症状が出ているなら、managed 側で catch して続けても意味がない、と考えたほうが安全です。

次に、ゾンビ化を疑う症状です。

ゾンビ化とは、落ちていないことではなく 仕事をしていないのに生きている ことです。最終処理時刻、滞留件数、heartbeat のように「動いていることを示す指標」を先に用意しておくと、継続か終了かの判断も、後追いの調査もかなり楽になります。

4. どこで起きたかで判断する

4.1 UI イベント

ボタンクリック、画面遷移、検索、ファイル選択のような UI イベントは、継続できる余地が比較的大きいです。 ただし、条件があります。

継続しやすいのは、こんな場合です。

• 読み込み前に失敗し、業務状態をまだ触っていない
• ダイアログ内の一時状態だけ壊れており、画面を閉じれば捨てられる
• 例外後に ViewModel や接続を作り直せる
• 利用者へ「今回の操作は失敗した」と正直に伝えられる

逆に、こうなってくると終了寄りです。

• 画面とドメイン状態の両方を途中まで更新した
• static / singleton / キャッシュなど、他画面も見る共有状態を触った
• 例外が起きたあと、ボタン活性や選択状態だけ残って整合が分からない
• UI スレッド上で unexpected な例外が起き、どこまで描画や通知が進んだか怪しい

4.2 1 件ずつ処理するジョブ / リクエスト

ここは、継続しやすい境界です。

• 1 メッセージ
• 1 ファイル
• 1 HTTP リクエスト
• 1 取り込みジョブ
• 1 バッチ対象

こうした単位が明確なら、その 1 件だけ失敗にして次へ進めます。

ただし、前提があります。

• 失敗単位が外から見て明確
• 途中変更がトランザクションや補償で整う
• 同じ処理をもう一度流しても結果が壊れない性質がある
• 失敗を隔離キューやエラー記録へ逃がせる

4.3 常駐ループ / 監視 / キュー処理

ここは、雑に継続すると一番まずい場所です。

たとえば:

• 再接続ループ
• 監視ループ
• キュー消費ループ
• 定期ポーリング
• 装置状態監視
• トレイアプリの常駐処理

この手の処理で怖いのは、親ループが 1 回の想定外例外で死に、プロセスだけ生き残ることです。

ここでは方針を分けたほうがよいです。

• 各アイテム処理の境界で想定内例外を捕まえる
• 親ループから想定外例外が漏れたら、プロセス終了寄りにする

4.4 起動処理

起動時の失敗を「とりあえず起動してから考える」にすると、機能の一部だけが欠けた状態で動き続けることになり、後から原因を切り分けにくくなります。

• 必須設定が読めない
• バージョン移行 / マイグレーションに失敗した
• 必須フォルダや証明書がない
• 中核サービスの初期化に失敗した
• 依存関係の構成が壊れている

こういう場合は、起動失敗として終了のほうが分かりやすいです。

4.5 ネイティブ境界 / COM / P/Invoke / unsafe

ここは別枠で少し厳しめに見たほうがよいです。

• COM
• P/Invoke
• C++/CLI の先
• vendor SDK
• callback で戻ってくる native 側コード
• unsafe を含む処理

特にこのあたりが見えたら終了寄りです。

• AccessViolationException
• ヒープ破壊やダブル free を疑う症状
• ハンドル異常、解放後アクセスの臭い
• callback 境界で突然死ぬ

5. 継続してよい条件

継続してよい条件をまとめると、こうなります。これらがだいたい揃っていることが前提です。

6. 終了したほうがよい条件

逆に、ここに当てはまるなら終了寄りです。

• 途中まで何を変更したか分からない
• 共有の書き換え可能な状態を触っていて、整合が読めない
• ロック、キュー、スレッド、監視ループの寿命管理が壊れた
• 外部副作用の重複 / 欠落 / 半端が説明できない
• 起動処理や中核インフラの初期化で失敗した
• ネイティブ境界やメモリ破壊を疑う

このレベルなら、きれいに継続する工夫より、落として復旧しやすくする工夫のほうが効きます。

7. 典型パターン別のおすすめ

3.1 の判断表は条件の形で書いてあるので、実際の場面に当てはめるときに迷うことがあります。この表は、その条件をよく見かける場面へ当てはめ直したものです。迷ったら、まず 3.1 で条件を確認し、それからこの表で近い行を探す順番が早いです。

8. よくある NG

8.1 catch (Exception) でログだけ出して続ける

これはかなり危険です。 原因を隠すうえに、壊れた状態を延命しやすいからです。

8.2 最後の未処理例外ハンドラで回復しようとする

AppDomain.UnhandledException、Application.ThreadException、DispatcherUnhandledException などは、最後に記録する場所としては有用ですが、魔法の回復ポイントではありません。

8.3 外部副作用があるのに安易に retry する

装置コマンド、メール送信、課金、ファイル移動、DB 更新などで同じ処理の再実行安全性がないまま retry すると、今度は二重実行事故が主役になります。

8.4 監視ループが死んだのに UI だけ残す

見た目だけ生きていて、仕事をしていないアプリは、利用者からは正常に見えるぶん発見が遅れます。3.4 のゾンビ化の症状が出ていないかを、監視側で拾えるようにしておきたいところです。

8.5 落とす設計をしていないのに「落としたくない」と言う

落としたくないなら、その前に入れておくものがあります。

• 自動再起動
• セッション復元
• 途中成果の保存
• 再実行安全性
• 障害領域の分離

9. 実装時の整理ポイント

9.1 catch する場所を境界に寄せる

深い層で何でも catch するより、

• UI 操作境界
• 1 リクエスト境界
• 1 ジョブ境界
• 1 接続境界
• プロセス境界

のように、失敗単位が定義できる場所で受けるほうが整理しやすいです。

たとえば、1 件ずつ処理する取り込みなら、catch はループの中に置きます。ここが失敗単位です。

// C# / .NET 8。1 件ずつ処理するループで、失敗単位をループの内側に閉じ込める例。
using System;
using System.Collections.Generic;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Extensions.Logging;

public sealed record ImportItem(string Id, string Payload);
public sealed record ImportFailure(string Id, string ExceptionType, string Message);
public sealed record ImportSummary(int Succeeded, IReadOnlyList<ImportFailure> Failed);

public interface IImportStore
{
    /// <summary>
    /// 1 件分の失敗(検証エラー、重複、書式不正など)は ImportItemException で投げる。
    /// それ以外は「この 1 件の問題」ではないので、そのまま外へ抜けさせる。
    /// </summary>
    Task SaveAsync(ImportItem item, CancellationToken cancellationToken);
}

/// <summary>捨てて次へ進んでよい、1 件分の失敗。</summary>
public sealed class ImportItemException(string message, Exception? inner = null)
    : Exception(message, inner);

public sealed class ImportRunner(IImportStore store, ILogger<ImportRunner> logger)
{
    public async Task<ImportSummary> RunAsync(
        IReadOnlyList<ImportItem> items,
        CancellationToken cancellationToken)
    {
        int succeeded = 0;
        List<ImportFailure> failed = [];

        foreach (ImportItem item in items)
        {
            cancellationToken.ThrowIfCancellationRequested();

            try
            {
                await store.SaveAsync(item, cancellationToken);
                succeeded++;
            }
            catch (ImportItemException ex)
            {
                // 1 件分の状態は捨てられるので、記録して次の 1 件へ進む。
                //
                // ここを catch (Exception) にしないこと。NullReferenceException や
                // OutOfMemoryException まで「ただの不良データ」として飲み込むと、
                // 4.3 で「ホストごと止める」と決めた想定外例外が親ループへ届きません。
                // 状態が信用できなくなった後も、残りの件を書き続けることになります
                logger.LogError(ex, "Import failed. ItemId={ItemId}", item.Id);
                failed.Add(new ImportFailure(item.Id, ex.GetType().Name, ex.Message));
            }
        }

        return new ImportSummary(succeeded, failed);
    }
}

逆に、この処理を回す 親ループ側では握りつぶさない のが対になる判断です。4.3 で書いたとおり、親ループが死んだままプロセスだけ残るのが一番まずい形なので、想定外例外はホストの停止につなげます。

// 常駐ループ側。停止要求は正常系として抜け、それ以外の想定外例外はホストごと止める。
using System;
using System.Collections.Generic;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

public interface IImportQueue
{
    Task<IReadOnlyList<ImportItem>> DequeueBatchAsync(CancellationToken cancellationToken);
}

public sealed class ImportWorker(
    IImportQueue queue,
    ImportRunner runner,
    IHostApplicationLifetime lifetime,
    ILogger<ImportWorker> logger) : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        try
        {
            using PeriodicTimer timer = new(TimeSpan.FromSeconds(10));

            while (await timer.WaitForNextTickAsync(stoppingToken))
            {
                IReadOnlyList<ImportItem> batch = await queue.DequeueBatchAsync(stoppingToken);
                ImportSummary summary = await runner.RunAsync(batch, stoppingToken);

                logger.LogInformation(
                    "Batch finished. Succeeded={Succeeded} Failed={Failed}",
                    summary.Succeeded,
                    summary.Failed.Count);
            }
        }
        catch (OperationCanceledException) when (stoppingToken.IsCancellationRequested)
        {
            // 停止要求は正常系。ここで静かに終わる。
        }
        catch (Exception ex)
        {
            // 親ループが壊れた = ワーカー全体の寿命が壊れている。
            // 握りつぶして「プロセスだけ生きている」状態を作らず、止めて再起動へ渡す。
            logger.LogCritical(ex, "Worker loop failed unexpectedly. Stopping the host.");

            // StopApplication は「正常に畳む」要求です。これだけだと、失敗時だけ
            // 再起動する監視側(サービスの回復操作、systemd の Restart=on-failure、
            // コンテナの restart ポリシー)からは「仕事を終えて正常終了した」と
            // 区別が付かず、二度と起き上がりません。
            //
            // Environment.ExitCode を立てるだけでも足りません。Windows サービスとして
            // 動かす場合、ホストが正常停止すると SCM へは SERVICE_STOPPED が
            // 報告され、ExitCode はサービスの終了状態に反映されないため、
            // 回復操作は走りません。0 以外の終了コードでプロセスを終了させます
            Environment.Exit(1);
        }
    }
}

Environment.Exit(1) を使っているところが要点です。IHostApplicationLifetime.StopApplication() は正常停止の要求なので、Windows サービスとして動かしている場合、SCM へは SERVICE_STOPPED が報告されます。プロセスの Environment.ExitCode はサービスの終了状態には反映されないため、サービスのプロパティで設定した回復操作(「サービスを再起動する」)は走りません。公式のワーカーサービスのチュートリアルも、既定の BackgroundServiceExceptionBehavior.StopHost は「きれいに止める」ので Windows のサービス管理側は再起動しない、回復操作を効かせるには 0 以外の終了コードで Environment.Exit を呼ぶ必要がある、と明記しています(11章の参考資料)。

Environment.Exit は今のプロセスを終わらせるので、落ちる前に出しておきたいログは、この行より前に書き切ってください。バッファリングするロガーを使っているなら、フラッシュを挟みます。逆に、Windows サービスではなく systemd やコンテナだけが相手なら、Environment.ExitCode を立ててから StopApplication() で畳む形でも監視側は失敗として扱えます。どちらの環境で動かすかで選んでください。

なお、ループの内側と外側で catch の役割が変わる点も押さえておきます。内側は失敗単位の記録、外側は寿命の終了です。ここを取り違えると、1 件の失敗でアプリが落ちたり、逆にワーカーが死んでもプロセスが生き残ったりします。

9.2 想定内例外と想定外例外を分ける

• 想定内: validation、not found、timeout、cancel、業務ルール違反
• 想定外: 前提崩れ、親ループ漏れ、ネイティブ境界異常、メモリ破壊臭

9.3 共有状態を小さくする

共有の書き換え可能な状態が大きいほど、継続判断は難しくなります。 逆に、1 画面 1 セッション 1 ワーカーの中へ閉じ込められるほど、失敗も閉じ込めやすくなります。

9.4 危険な処理は別プロセスへ逃がす

COM / ActiveX / vendor SDK / unsafe / 重い画像処理 / 外部機器制御など、落ちたときの被害を広げたくないものは、別プロセス化がかなり効きます。

9.5 未処理例外ハンドラは「回復」より「記録」

• 例外情報
• 操作文脈
• 直前の重要ログ
• 設定 / バージョン / 接続先
• dump 採取導線

このあたりを揃えて、落ちたあとに詰められる形を優先したほうが、結果として安定します。

WPF なら、記録用のハンドラーはこのくらいの形で足ります。

// WPF (.NET 8) の App.xaml.cs。ハンドラーは「回復」ではなく「記録」に使う。
using System;
using System.IO;
using System.Reflection;
using System.Threading.Tasks;
using System.Windows;

namespace SampleApp;

public partial class App : Application
{
    private static readonly string CrashLogPath = Path.Combine(
        Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData),
        "SampleApp",
        "crash.log");

    protected override void OnStartup(StartupEventArgs e)
    {
        // ハンドラーの登録は base.OnStartup(e) より前に置く。
        // base.OnStartup は Startup イベントを発火させるので、その購読側で例外が
        // 出ると、後ろに書いたハンドラーはまだ登録されておらず、
        // 「起動時に落ちたのにログが1行も残らない」という一番困る形になる。
        // 起動処理そのものの失敗こそ記録したいので、先に張っておく。

        // UI スレッドで未処理のまま上がってきた例外
        DispatcherUnhandledException += (_, args) =>
        {
            Record("DispatcherUnhandledException", args.Exception);

            // args.Handled = true にすれば続行できるが、続けてよいかは 5 章の条件で判断する。
            // 判断がつかないなら、記録して既定動作（終了）に任せる。
            args.Handled = false;
        };

        // UI スレッド以外も含む最後の通知。ここでは止められないので記録専用。
        AppDomain.CurrentDomain.UnhandledException += (_, args) =>
            Record("AppDomain.UnhandledException", args.ExceptionObject as Exception);

        // await されないまま回収された Task の例外
        TaskScheduler.UnobservedTaskException += (_, args) =>
        {
            Record("UnobservedTaskException", args.Exception);
            args.SetObserved();
        };

        // ここまで張り終えてから、既定の起動処理(Startup イベントの発火)へ進む
        base.OnStartup(e);
    }

    private static void Record(string source, Exception? exception)
    {
        try
        {
            Directory.CreateDirectory(Path.GetDirectoryName(CrashLogPath)!);

            string version = Assembly.GetExecutingAssembly().GetName().Version?.ToString() ?? "unknown";
            string text = string.Join(
                Environment.NewLine,
                $"[{DateTimeOffset.Now:O}] {source}",
                $"version={version} os={Environment.OSVersion} user={Environment.UserName}",
                exception?.ToString() ?? "(no exception object)",
                string.Empty);

            File.AppendAllText(CrashLogPath, text);
        }
        catch
        {
            // 記録に失敗しても、終了処理を止めない。
        }
    }
}

ポイントは、ハンドラーの中で状態を直そうとしないことです。ここでやるのは、次に同じ現象を追える材料を残すことだけです。

9.6 WPF / WinForms の未処理例外イベントを過信しない

WPF では DispatcherUnhandledException で Handled = true にすると、未処理例外後も続けること自体はできます。 Windows Forms でもメイン UI スレッドでは Application.ThreadException や SetUnhandledExceptionMode の設定次第で止め方を選べます。

ただ、それで続けられるかどうかと、回復条件が揃っているか は別の問題です。

9.7 Environment.FailFast は「片づけるほうが危険」なときだけ

3.1 のフローチャートに出てくる FailFast は、Environment.FailFast のことです。公式ドキュメントに書かれている挙動は次のとおりです。

• 実行中の try / finally も finalizer も 走らせずに プロセスを終了する
• Windows では、渡したメッセージを Windows のアプリケーション イベント ログ へ書き、アプリケーションのダンプを作成 してから終了する
• メッセージと例外情報は、Windows エラー報告経由で Microsoft へのエラー報告にも含まれる
• Visual Studio のデバッガー下で呼ぶと ExecutionEngineException になり、fatalExecutionEngineError の managed debugging assistant が発生する

finally を走らせないのは欠点ではなく、この API の目的です。状態が壊れているときに後片づけコードを走らせると、壊れた内容をそのままファイルや DB へ書いてしまうことがあるからです。ドキュメントでも、アプリの状態が修復不能に壊れており、try / finally や finalizer を実行するとリソースを壊してしまう場合は Environment.Exit ではなく FailFast を使う、と説明されています。

使い分けは、こうなります。

コードにすると、次のような場所で使います。

// C# / .NET 8。共有状態の不変条件が壊れたことを検出した箇所。
// ここから先は、どの後片づけ処理も信用できない。
if (cache.Count != store.Count)
{
    Environment.FailFast(
        $"Invariant broken: cache={cache.Count} store={store.Count}",
        new InvalidOperationException("Cache and store are out of sync."));
}

ダンプが自動で採取されるので、FailFast に渡すメッセージには どの不変条件が、どの値で壊れていたか を入れておくと、後の調査がかなり楽になります。逆に、入力ミスや通信エラーのような想定内の失敗で FailFast を呼ぶのは過剰です。そこは 9.1 の失敗単位の話に戻ります。

10. まとめ

想定していない例外が起きたときに見るべきなのは、「この例外は catch できるか」ではなく、このあともアプリの状態を信用できるかです。

判断の順番としては、だいたいこれで十分です。

1. 失敗した単位を捨てられるか
2. 共有状態を戻せるか、作り直せるか
3. 外部副作用を説明できるか
4. メモリ / スレッド / ネイティブ境界の健全性は信用できるか

この 4 つに自信があるなら継続できます。 自信がないなら、終了寄りです。

特に、長時間動くアプリ、監視アプリ、サービス、装置連携では、壊れたまま生きることのほうが、素直に落ちることより危険な場面がかなりあります。

例外処理は「落とさない技術」ではありません。 壊れ方を小さくし、壊れたら正直に止まり、復旧しやすくする設計です。

11. 参考資料

• .NET: Best practices for exceptions
• .NET: Create a Windows Service using BackgroundService（既定の BackgroundServiceExceptionBehavior.StopHost はホストをきれいに止めるため Windows のサービス管理側は再起動しないこと、回復操作を効かせるには 0 以外の終了コードで Environment.Exit を呼ぶ必要があること）
• .NET: System.Exception
• .NET: StackOverflowException
• .NET: System.AccessViolationException
• .NET: Environment.FailFast
• .NET: AppDomain.UnhandledException
• WPF: Application.DispatcherUnhandledException
• Windows Forms: Application.SetUnhandledExceptionMode
• .NET: Exceptions in Managed Threads
• .NET: TaskScheduler.UnobservedTaskException
• Windows: NTSTATUS Values - MS-ERREF

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

想定外の例外をcatch (Exception)で握りつぶして続行してはいけないのですか？

ログだけ出して続けるのはだいたい危険です。原因を隠すうえに、壊れた状態を延命しやすいからです。継続してよいのは、失敗した単位を捨てられる、共有状態を元に戻せる、外部副作用を説明できる、の3つが揃うときです。判断の軸は「この例外は catch できるか」ではなく「このあともアプリの状態を信用できるか」です。

どんな例外が出たら即終了すべきですか？

StackOverflowException、AccessViolationException、深刻なOutOfMemoryExceptionのように、プロセス全体の健全性を疑う例外は継続前提で考えないほうが安全です。StackOverflowExceptionは呼び出しスタックが破綻しており、AccessViolationExceptionは保護メモリへの不正アクセスでメモリ破壊が疑われます。COM・P/Invoke・vendor SDKのcallback起点の異常も、managed側だけ見ても安全性を判断しづらいため強めの終了寄りです。

例外が起きてもアプリを継続してよいのはどんな条件ですか？

失敗単位が明確（1操作・1画面・1ジョブ・1接続など捨てる単位が分かる）、状態を破棄して作り直せる、共有状態へ汚染が広がらない、外部副作用を説明できる、利用者へ「今回の処理は失敗した」と正直に伝えられる、ログやメトリクスで後追い調査できる、という条件がだいたい揃っていることが前提です。UIの1操作や1件の取り込みジョブのように処理境界が明確なら継続できることがあります。逆に共有状態の更新途中、親ループ、起動処理、ネイティブ境界の異常は終了寄りです。

WPFのDispatcherUnhandledExceptionでHandled=trueにすれば継続できますか？

未処理例外後も続けること自体はできますが、続けられることと続けて安全なことは別問題です。AppDomain.UnhandledExceptionやDispatcherUnhandledExceptionなどのハンドラは、最後に記録する場所としては有用ですが、魔法の回復ポイントではありません。例外情報・操作文脈・ダンプ採取導線を揃えて落ちたあとに調査できる形を優先するほうが、結果として安定します。特に長時間動くサービスや監視アプリは、半分壊れたまま生き延びるより落ちて再起動されるほうが診断もしやすく安全なことが多いです。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。