この記事のポイント

  • 組込み・リアルタイム領域における例外禁止設計のレビュー観点を体系整理
  • 設計責務・運用性・安全性の観点からレビューアーが設計意図を読み解く実務技術を習得
  • 例外禁止設計の合理性と妥当性をレビュー文化として支援可能にする

そもそも組込み/リアルタイム例外禁止設計とは何か

C++では本来例外機構が用意されているが、
組込み系・リアルタイム系では例外そのものを禁止する設計方針が主流である。

領域 方針理由
組込みマイコン ヒープ管理不能、ランタイム膨張不可
リアルタイム制御 不定分岐禁止、割込み優先性制御維持
安全規格適合 動作経路予測性強化

レビューアーは「このプロジェクトの例外禁止は運用要求・安全要求に基づくか？」を読み解く視点が必要。

なぜこれをレビューするのか

  • 例外禁止理由が文化依存化し属人判断になるケースが多発
  • 禁止範囲が曖昧になると混在設計で事故が誘発される
  • レビュー段階で設計理由明文化・封じ込め統一が必要

レビューアーは設計方針宣言そのものの妥当性レビューを担う技術力が求められる。

レビューアー視点

  • 例外禁止が安全性要件・制御要件から導かれているか？
  • 禁止範囲（全層禁止／公開層禁止）が明文化されているか？
  • 例外機能利用禁止がビルドオプションレベルで強制化されているか？
  • 代替エラー処理体系（戻り値型・通知層）が整理されているか？
  • 運用監視系統が統一経路で構成されているか？

開発者視点

  • 例外禁止設計＝「動作経路を静的に決定できる設計体系」の宣言
  • ヒープ依存機能（文字列組立・型id活用）は原則排除
  • 戻り値型にError Code体系を統一導入
  • 封じ込め層で外部例外系・標準ライブラリ例外系を吸収変換

良い実装例

例1：戻り値統一Error Code設計

enum class SaveResult {
    Success,
    ValidationError,
    HardwareFailure,
    StorageFailure
};

SaveResult saveUser(const User& user) {
    if (!validate(user)) return SaveResult::ValidationError;
    if (!hardwareReady()) return SaveResult::HardwareFailure;
    if (!writeStorage(user)) return SaveResult::StorageFailure;
    return SaveResult::Success;
}
  • 全障害系統が静的分岐整理

例2：標準ライブラリ例外封じ込め層

SaveResult storageWrite(const std::string& data) {
    try {
        file.write(data);
        return SaveResult::Success;
    } catch (...) {
        return SaveResult::StorageFailure;
    }
}
  • 外部例外系は封じ込め層で吸収変換

レビュー観点

  • 例外禁止方針の設計資料宣言が存在するか
  • 全API契約が戻り値型統一されているか
  • 標準ライブラリ活用部に封じ込め吸収層が存在するか
  • 動作経路が全て静的決定可能経路化されているか
  • モニタリング通知設計が障害分類整理と統一されているか

良くない実装例: ケース1（方針曖昧設計）

void save() {
    db.write();

@Reviewer
例外禁止方針適用下でdb.writeの例外発生可能性が放置されています。封じ込め層設計してください。
}

改善例

SaveResult save() {
    try { db.write(); return SaveResult::Success; }
    catch (...) { return SaveResult::StorageFailure; }
}

良くない実装例: ケース2（API層混在）

SaveResult saveConfig();
void saveLog();

@Reviewer
API群内で戻り値型と例外型が混在しています。全APIで統一型を固定宣言してください。

改善例

SaveResult saveLog();

良くない実装例: ケース3（通知経路崩壊）

SaveResult save();
if (save() != SaveResult::Success) {
    // ログ出力欠落

@Reviewer
エラーコード発生時の監視通知経路が不統一です。通知統一設計してください。
}

改善例

if (save() != SaveResult::Success) {
    monitoring.notify("SAVE_FAILURE");
}

PlantUML：例外禁止動作経路整理図

UML Diagram

例外禁止設計理由整理表

禁止理由 技術背景
ヒープ管理不能 小容量固定メモリのみ
実行経路不定化 リアルタイム優先性破壊
標準ライブラリ非適合 STL例外透過不能
安全規格非適合 MISRA, AUTOSAR準拠

レビューアーは設計理由の背景階層を説明可能に整理する技術力を養成する。

監視通知経路統一設計例

SaveResult result = save();
if (result != SaveResult::Success) {
    logger.error("Save failed with result {}", static_cast<int>(result));
    monitoring.notify("SAVE_FAILURE");
}
  • 通知文化を例外有無と無関係に統一整理

封じ込め層設計テンプレート

層分類 封じ込め処理
標準ライブラリ層 try-catch全吸収変換
外部ライブラリ層 Adapter吸収封じ込め
自社ユーティリティ層 ErrorCode変換API統一

レビューアーは封じ込め層を静的に全網羅レビュー可能に整理する必要がある。

典型レビュー質問集

質問例 意図
例外禁止方針は設計資料で正式宣言されていますか？ 方針可視化確認
封じ込め層は標準ライブラリを網羅吸収していますか？ 外部例外遮断確認
戻り値型設計はAPI群で統一されていますか？ 統一文化確認
動作経路は静的決定可能ですか？ リアルタイム保証確認
監視通知経路は障害分類整理と統合されていますか？ 運用安定性確認

レビューアーは例外禁止文化レビューの標準化役割を担う。

観点チェックリスト

まとめ

レビューアーが組込み/リアルタイム例外禁止設計レビューで常に問うべきは
「この例外禁止方針は技術的要件整理に基づく正当な宣言か？」
です。

  • 禁止方針明文化文化 → 設計資料責務文化
  • 封じ込め文化 → 標準ライブラリ遮断文化
  • API統一文化 → 戻り値型固定文化
  • 運用安定文化 → 通知整理文化

レビュー現場では
「例外禁止設計の背景理由をレビュー文化で整理固定する」
ことが長期安全性・保守性・運用品質を大きく左右します。