この記事のポイント

• 予測可能エラーと致命的異常のレビュー観点を体系整理
• 設計責務としてのエラーパス分離をレビューアーが読み解き整理する力を習得
• 設計文化としての分類整理をレビュー支援で定着させる

そもそも予測可能エラーと致命的異常系とは何か

C++設計では発生する障害を次の2種類に整理できる。

レビューアーは「これは予測可能エラーか？致命的異常か？」を即座に読み取れる視点が必須になる。

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

• 設計初期で分類整理せず後手に回る現場が多発
• 混在設計進行で運用障害／設計バグが区別不能化
• リトライ可否／監視通知系が崩壊しやすい
• 保守運用コスト肥大の主因になる

レビューアーがエラーパス分類設計支援を提供する役割を持つことで設計品質を底上げできる。

レビューアー視点

• これは利用者入力起因の予測可能系か？
• 設計バグ起因の契約違反系か？
• 復旧可否を事前に宣言可能な分類設計か？
• 障害通知系は分類統一設計されているか？
• テストケースで両分類を独立確認可能になっているか？

開発者視点

• 契約違反は設計責務違反 → 例外／assert統一
• 利用者起因は予測可能系 → エラーコード／例外通知統一
• 監視通知は復旧性分類に沿って整理
• 設計初期で各関数毎に「どちらに分類か」明文化

良い実装例

例1：予測可能エラー通知例

void registerUser(const User& u) {
    if (u.id <= 0) {
        throw std::invalid_argument("Invalid user id");
    }
    if (!db.save(u)) {
        throw DatabaseUnavailable("DB failure");
    }
}

• 入力不正 → invalid_argument
• 外部障害 → custom exception

例2：契約違反系設計

void save(const User* u) {
    assert(u != nullptr);
}

• nullptr許容不可 → 設計契約違反として明文化

レビュー観点

• 入力系 vs 設計契約系が整理されているか
• 外部依存障害 vs 内部構造崩壊が分離設計されているか
• 再試行可能系 vs 不可系が整理設計されているか
• 通知経路分類（監視アラート分類）が設計と連動しているか
• テストケースが分類網羅できているか

良くない実装例: ケース1（契約違反曖昧）

void save(User* u) {
    if (!u) return;
    db.save(*u);
@Reviewer
nullptr許容は設計契約放棄です。契約違反検出をassert等で明文化してください。
}

改善例

assert(u != nullptr);

良くない実装例: ケース2（予測系混在崩壊）

void process(User u) {
    if (u.id <= 0) throw "invalid";
    if (!db.save(u)) throw "fail";
@Reviewer
予測系分類が不明確です。標準例外とCustom例外で分類整理してください。
}

改善例

throw std::invalid_argument("Invalid id");
throw DatabaseUnavailable("DB failure");

良くない実装例: ケース3（通知系混乱）

try {
    service.process();
} catch (...) {
    monitoring.notify("FAILURE");
@Reviewer
予測系／致命系の分類通知が崩壊しています。障害種別分類統合してください。
}

改善例

monitoring.notify("DB_FAILURE");
monitoring.notify("INPUT_INVALID");

PlantUML：異常分類責務整理図

エラーパス分類整理表

レビューアーはこの表を常に実装脈絡で読み替え可能にする技術力が求められる。

通知系統一設計例

try {
    service.process();
} catch (const std::invalid_argument& e) {
    monitoring.notify("INPUT_INVALID");
} catch (const DatabaseUnavailable& e) {
    monitoring.notify("DB_FAILURE");
} catch (...) {
    monitoring.notify("FATAL_FAILURE");
}

• 通知経路が分類整理済み

障害分類レビュー質問集

レビューアーは障害分類支援レビュー文化を現場に定着させる役割を持つ。

観点チェックリスト

• 予測可能系 vs 致命的異常系の分類が初期設計で宣言されているか
• 契約違反条件がassert等で整理されているか
• 入力不正系が例外型で整理されているか
• 外部依存系が障害種別で整理されているか
• 監視通知設計が分類連動されているか
• テスト系統網羅で各分類を独立検証できているか

まとめ

レビューアーが異常系分類レビューで常に問うべきは
「この障害は設計上どの層の責務で復旧可否がどうなるか？」
です。

• 予測可能系 → 利用者・外部障害層で整理
• 致命的異常系 → 設計責務違反層で整理
• 通知整理 → 運用監視系統一
• 継続性文化 → 設計資料常時更新

レビュー現場では
「異常系を分類整理するレビュー文化」
が品質・運用負荷・保守生産性を劇的に安定させます。