error-classification

Error, Defect, Fault, Failure Classification Guide

Accurately classify abnormal states of software and derive appropriate handling strategies.

Why Classification Matters

Error, Defect, Fault, and Failure are easily confused, but each is a distinct concept, and the handling strategies also differ. Using the terms ambiguously can lead to erroneous design decisions.

Comparison of Definitions by Standard

Type	Error	Defect	Fault	Failure
JIS X 0014:1999	A mismatch in value or state (not including human error)	-	An abnormal state that causes degradation or loss of the capability of a functional unit	The loss of the capability of a functional unit to perform a required function
JIS Z 8115:2000	A mismatch in value or condition (including human error)	-	The state of an item that is unable to perform its function	An item losing the ability to achieve its required function
JSTQB	A human act that produces an incorrect result	A deficiency that causes a function to be unrealizable (including bugs)	Synonymous with Defect	Deviating from the expected function
Bertrand Meyer	An incorrect decision made during development	A characteristic that causes the system to deviate from its intended behavior	An event that deviates from the intended behavior during execution	-
JIS Q 9000:2006	-	Failure to satisfy requirements related to the intended use	-	-

Practical Interpretation

Error

A state of discrepancy between an input value and an expected value.

• Validation error (input value is outside the expected range)
• A recoverable, anticipated event such as a file not existing
• The caller can handle it

例: ユーザー入力のメールアドレス形式不正、存在しないリソースへのアクセス
対処: Either/Result型で表現し、呼び出し元に判断を委ねる

Defect

A state that does not satisfy requirements. Includes bugs. Something that should not occur in the first place.

• Breach of contract (Design by Contract)
• The caller has not satisfied the preconditions
• Should be handled with assertions

例: null不可の引数にnullが渡された、不正な状態遷移の試行
対処: アサーション（require/assert）で即座に検出・停止

Fault

An abnormal state in which the function cannot be performed. Unrecoverable.

• A bug in the callee or unclear responsibility
• An abnormal state of the system
• In Akka/Erlang, resilience can be achieved with the Error Kernel and Let it crash patterns

例: DBコネクション枯渇、メモリ不足、外部サービスの完全停止
対処: 障害の隔離（Error Kernel）、監視と再起動（Let it crash）

Failure

A state in which the ability to achieve the function has been lost.

• As a result of the Fault not being resolved, the system becomes unable to provide the function
• The final symptom as seen by the user

例: サービス全体のダウン、レスポンス不能
対処: 冗長化、フェイルオーバー、サーキットブレーカー

Causal Relationship

Error（エラー）
  → 想定内。呼び出し元で対処可能

Defect（欠陥）
  → 本来あってはならない。アサーションで検出
  → 修正されなければ Fault を引き起こす

Fault（障害）
  → 異常状態。リカバリ困難
  → 継続すると Failure に至る

Failure（故障）
  → 機能喪失。ユーザーに影響

Application to Design

Handling Strategies Based on Classification

Classification	Handling Strategy	Implementation Pattern
Error	Handle at the Caller	Either/Result types, validation
Defect	Detect and Stop Immediately	Assertions (require/assert), precondition checks
Fault	Isolation and Recovery	Error Kernel, Let it crash, Circuit breaker
Failure	Prevention and Redundancy	Failover, redundant configuration, monitoring and alerts

Decision Flow

非正常状態が発生
    ↓
呼び出し元で想定・対処可能か？
    ├─ YES → Error（エラー）
    │         → Either/Result型で表現
    └─ NO ↓
        本来発生してはいけない状態か？（契約違反）
        ├─ YES → Defect（欠陥）
        │         → アサーションで即座に停止
        └─ NO ↓
            機能が遂行不可能な異常状態か？
            ├─ YES → Fault（障害）
            │         → 隔離・監視・再起動
            └─ 機能達成能力を喪失
                → Failure（故障）
                → フェイルオーバー・冗長化

error-handling Relationship with Skills

This skill deals with theclassification and conceptual definitionof abnormal states. For specific implementation patterns (how to use Either/Result types, language-specific libraries, etc.), refer to the error-handling skill.

Perspective	This Skill	error-handling skill
Focus	Classification and definition of concepts	Implementation patterns
Target	Error/Defect/Fault/Failure as a whole	Mainly Error handling
Use	Design decisions, terminology unification	Coding review

Review checklist

• Within error handling code, are Error/Defect/Fault/Failure properly distinguished
• Are expected Errors (validation, etc.) expressed with Result types
• Are Defects (contract violations) detected with assertions
• Are Error and Defect not confused and handled the same way
• Does an isolation/recovery strategy exist for Faults
• Are exceptions "caught no matter what", thereby swallowing Defects

Related Skills (Recommended Reading)

When using this skill, also refer to the following skills:

• error-handling: Implementation patterns for error handling based on classification (Either/Result, exceptions, etc.)
• aggregate-design: Distinguishing invariant violations from domain errors in aggregate operations
• domain-building-blocks: Error classification when constructing value objects