System Design (LLD)Errors vs Exceptions

Errors vs Exceptions: Foundations of Robust Error Handling

LevelIntermediate

Duration60 mins

TopicErrors vs Exceptions

2 / 4

What is an Exception

The Mechanism Behind Error Signaling

In the previous page, we established what an error is: a deviation from expected behavior, a contract violation, a state where the system cannot proceed normally. But once an error is detected, how does one part of the system tell another part that something went wrong?

This is where exceptions enter the picture. An exception is not an error itself—it is a mechanism for signaling that an error has occurred. Understanding this distinction is crucial for designing effective error handling strategies.

Exceptions are one of the most powerful and most misused features in modern programming languages. Used well, they enable clean separation of error handling from business logic. Used poorly, they create spaghetti control flow, hide bugs, and make systems impossible to reason about.

What You Will Learn

By the end of this page, you will understand the precise definition of an exception, how exceptions work at the language and runtime level, the anatomy of exception handling constructs, and the fundamental tradeoffs exceptions introduce into system design.

Defining Exceptions: The Signal, Not the Problem

An exception is a runtime event that disrupts the normal flow of a program's execution to signal that an error condition has occurred. Critically, the exception is the messenger, not the message itself.

The Key Distinction:

Concept	Analogy	Role
Error	A fire in a building	The actual problem
Exception	The fire alarm	The mechanism that signals the problem

Just as a fire alarm doesn't cause the fire (it signals its presence), an exception doesn't cause the error (it signals its detection).

Formal Definition:

An exception is a language construct that:

Interrupts normal sequential execution
Transfers control to a designated handler
Carries information about the error condition
Propagates up the call stack if not handled locally

exception-signaling-example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
/**
 * The Error: Invalid account state (business rule violation)
 * The Exception: The thrown Error object that signals this condition
 */
class InsufficientFundsError extends Error {
    constructor(
        public readonly accountId: string,
        public readonly requestedAmount: number,
        public readonly availableBalance: number
    ) {
        super(
            `Insufficient funds in account ${accountId}: ` +
                                        `requested ${requestedAmount}, available ${availableBalance}`
        );
        this.name = 'InsufficientFundsError';
    }
}
 
class BankAccount {
    private balance: number;
    
    constructor(
        private readonly accountId: string, 
        initialBalance: number
    ) {
        this.balance = initialBalance;
    }
    
    /**
     * Attempts to withdraw money from the account.
     * 
     * When an ERROR condition is detected (insufficient funds),
     * an EXCEPTION is thrown to signal this to the caller.
     */
    withdraw(amount: number): void {
        // Detect the error condition
        if (amount > this.balance) {
            // Signal the error by throwing an exception
            // The error IS the insufficient funds condition
            // The exception IS the InsufficientFundsError object
            throw new InsufficientFundsError(
                this.accountId,
                amount,
                this.balance
            );
        }
        
        // Normal execution path
        this.balance -= amount;
    }
}
 
// The exception propagates until caught
function transferFunds(from: BankAccount, to: BankAccount, amount: number): void {
    // If withdraw throws, this function also "throws" (propagates)
    from.withdraw(amount);
    
    // This line only executes if no exception was thrown
    to.deposit(amount);
}

How Exceptions Work: Under the Hood

To use exceptions effectively, we need to understand how they work at the runtime level. This knowledge informs performance considerations and helps us reason about control flow.

The Exception Mechanism:

When an exception is thrown, the runtime performs these steps:

Exception object creation: An object representing the error is instantiated, typically including a message, stack trace, and other context.
Stack unwinding: The runtime searches up the call stack for an exception handler that can handle this exception type.
Handler matching: At each stack frame, the runtime checks if there's a matching catch block. Matching typically follows type hierarchy—a handler for Exception catches its subclasses.
Handler execution: When a matching handler is found, control transfers to it. The stack frames between the throw site and the handler are discarded.
Normal resumption or propagation: After the handler completes, execution continues normally, or the exception is re-thrown to propagate further.

Converting Mermaid diagram...

Performance Implications:

Exception handling involves runtime costs that differ from normal control flow:

Exception Handling Performance Characteristics
Aspect	Normal Path (no exception)	Exception Path
Try block entry	Negligible (register setup)	N/A
Normal execution	Zero overhead in modern runtimes	N/A
Exception creation	N/A	Moderate (object allocation, stack trace capture)
Stack unwinding	N/A	Costly (proportional to stack depth)
Handler execution	N/A	Normal execution cost

Performance Insight

Modern exception implementations follow 'zero-cost exceptions' design: the happy path (no exception thrown) has virtually no overhead. The cost is paid only when an exception is actually thrown. This makes exceptions appropriate for truly exceptional conditions but inappropriate for normal control flow.

exception-overhead-demonstration
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
/**
 * Demonstrating why exceptions shouldn't be used for control flow
 */
 
// BAD: Using exceptions for expected outcomes
function findUserBad(users: User[], id: string): User {
    const user = users.find(u => u.id === id);
    if (!user) {
        throw new Error("User not found");  // Expected case treated as exception
    }
    return user;
}
 
// Processing 10,000 lookups where 50% are not found:
// - 5,000 exception throws
// - 5,000 stack traces captured
// - 5,000 stack unwinds
// Result: Massive performance degradation
 
// GOOD: Expected outcomes returned normally
function findUserGood(users: User[], id: string): User | null {
    return users.find(u => u.id === id) ?? null;
}
 
// Processing 10,000 lookups where 50% are not found:
// - 10,000 simple returns (null or user)
// - Zero exception overhead
// Result: Optimal performance
 
 
// APPROPRIATE: True exceptions for actual exceptional conditions
function getRequiredConfig(key: string): string {
    const value = process.env[key];
    if (!value) {
        // This IS exceptional: the app cannot function without this config
        // This should happen 0 times in normal operation
        throw new ConfigurationError(`Required config missing: ${key}`);
    }
    return value;
}

Anatomy of Exception Constructs

Most languages provide a standard set of constructs for working with exceptions. Understanding each piece is essential for effective exception handling.

The Core Constructs:

Exception Handling Constructs

•throw / raise: Signals an exception, transferring control to the nearest matching handler. Creates the exception object and initiates stack unwinding.
•try: Defines a protected block of code where exceptions will be caught. Establishes a 'checkpoint' in the stack for exception handling.
•catch / except: Defines a handler for specific exception types. Controls which exceptions are handled and what action to take.
•finally / ensure: Defines cleanup code that runs regardless of whether an exception occurred. Essential for resource management.
•rethrow: Propagates a caught exception to the next handler up the stack. Allows partial handling before escalation.

exception-construct-anatomy
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
/**
 * Comprehensive example showing all exception constructs
 */
class DatabaseConnection {
    private isOpen = false;
    
    open(): void {
        console.log("Opening database connection");
        this.isOpen = true;
    }
    
    close(): void {
        console.log("Closing database connection");
        this.isOpen = false;
    }
    
    execute(query: string): Result {
        if (!this.isOpen) {
            throw new Error("Connection not open");
        }
        // Execute query...
        return { rows: [] };
    }
}
 
async function processTransaction(data: TransactionData): Promise<void> {
    const connection = new DatabaseConnection();
    
    try {
        // TRY block: Protected code where exceptions are monitored
        connection.open();
        
        const result = await validateData(data);
        
        if (!result.isValid) {
            // THROW: Signal an error condition
            throw new ValidationError(
                "Transaction data is invalid",
                result.errors
            );
        }
        
        await connection.execute("BEGIN TRANSACTION");
        await connection.execute(`INSERT INTO transactions...`);
        await connection.execute("COMMIT");
        
    } catch (error) {
        // CATCH block: Handle specific exception types
        
        if (error instanceof ValidationError) {
            // Handle validation errors specifically
            console.error("Validation failed:", error.errors);
            await notifyUser(error.message);
            // Don't rethrow - this is fully handled
            
        } else if (error instanceof DatabaseError) {
            // Handle database errors
            console.error("Database error:", error.message);
            await connection.execute("ROLLBACK").catch(() => {});
            
            // RETHROW: Propagate to caller for further handling
            throw error;
            
        } else {
            // Unknown error - wrap and rethrow
            throw new TransactionError(
                "Unexpected error during transaction",
                { cause: error }
            );
        }
        
    } finally {
        // FINALLY block: Cleanup that ALWAYS runs
        // Runs after try (if no exception)
        // Runs after catch (if exception was caught)
        // Runs even if exception is rethrown
        
        connection.close();  // Resource cleanup guaranteed
        console.log("Transaction processing completed");
    }
}

Finally Block Gotchas

The finally block runs even when an exception is being propagated. Avoid throwing exceptions from finally blocks—doing so will mask the original exception. Also avoid returning from finally blocks, as this can cause the original exception to be silently swallowed.

Exception Types and Hierarchies

Most languages organize exceptions into hierarchies that enable flexible catching patterns. Understanding these hierarchies is essential for designing custom exceptions and writing appropriate catch blocks.

Common Exception Hierarchy Patterns:

Converting Mermaid diagram...

Key Categories in Exception Hierarchies:

Exception Hierarchy Categories
Category	Examples	Should Catch?	Typical Cause
Errors (Fatal)	OutOfMemoryError, StackOverflow	Usually no	JVM/runtime failure, cannot recover
Unchecked (Runtime)	NullPointer, IllegalArgument	Selectively	Programming bugs, invalid state
Checked (Anticipated)	IOException, SQLException	Yes, required	External failures, expected problems
Custom Business	InsufficientFunds, UserNotFound	Yes, specific	Domain-specific error conditions

exception-hierarchy-design
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
/**
 * Well-designed exception hierarchy for a payment processing system
 */
 
// Base exception for all application errors
abstract class ApplicationError extends Error {
    abstract readonly code: string;
    abstract readonly isRetryable: boolean;
    
    constructor(message: string, public readonly cause?: Error) {
        super(message);
        this.name = this.constructor.name;
        
        // Capture stack trace (V8 engines)
        if (Error.captureStackTrace) {
            Error.captureStackTrace(this, this.constructor);
        }
    }
}
 
// Category: Domain/Business Errors
abstract class DomainError extends ApplicationError {
    readonly isRetryable = false;  // Business errors aren't retryable
}
 
class InsufficientFundsError extends DomainError {
    readonly code = 'INSUFFICIENT_FUNDS';
    
    constructor(
        public readonly accountId: string,
        public readonly required: number,
        public readonly available: number
    ) {
        super(`Account ${accountId} has insufficient funds`);
    }
}
 
class AccountLockedError extends DomainError {
    readonly code = 'ACCOUNT_LOCKED';
    
    constructor(
        public readonly accountId: string,
        public readonly reason: string
    ) {
        super(`Account ${accountId} is locked: ${reason}`);
    }
}
 
// Category: Infrastructure Errors
abstract class InfrastructureError extends ApplicationError {}
 
class DatabaseError extends InfrastructureError {
    readonly code = 'DATABASE_ERROR';
    readonly isRetryable = true;
    
    constructor(message: string, cause?: Error) {
        super(`Database operation failed: ${message}`, cause);
    }
}
 
class NetworkError extends InfrastructureError {
    readonly code = 'NETWORK_ERROR';
    readonly isRetryable = true;
    
    constructor(
        public readonly endpoint: string,
        cause?: Error
    ) {
        super(`Network request to ${endpoint} failed`, cause);
    }
}
 
// Category: Validation Errors
class ValidationError extends ApplicationError {
    readonly code = 'VALIDATION_ERROR';
    readonly isRetryable = false;
    
    constructor(
        message: string,
        public readonly field: string,
        public readonly violations: string[]
    ) {
        super(message);
    }
}
 
 
// Usage: Catch by category for flexible handling
async function processPayment(payment: Payment): Promise<void> {
    try {
        await paymentGateway.process(payment);
        
    } catch (error) {
        if (error instanceof DomainError) {
            // Business rule violation - inform user
            throw new UserFacingError(error.message, error.code);
            
        } else if (error instanceof InfrastructureError && error.isRetryable) {
            // Infrastructure issue - retry
            await retryWithBackoff(() => paymentGateway.process(payment));
            
        } else {
            // Unknown error - escalate
            throw error;
        }
    }
}

Hierarchy Design Principle

Design your exception hierarchy around how errors should be handled, not just what went wrong. Exceptions that should be handled the same way should share a common ancestor. This enables catch blocks like 'catch (InfrastructureError)' that handle all infrastructure failures uniformly.

Exception Chaining and Wrapping

In layered systems, exceptions often need to cross architectural boundaries. A low-level database exception shouldn't leak through to the presentation layer. Exception chaining (also called wrapping or nesting) solves this while preserving diagnostic information.

Why Chain Exceptions?

Benefits of Exception Chaining

•Abstraction preservation: Higher layers deal with domain-appropriate exceptions, not low-level technical details.
•Root cause preservation: The original exception is captured for debugging, not lost.
•Context enrichment: Each layer can add its own context to the error.
•Type safety: Catch blocks can match on the appropriate abstraction level.
•Information hiding: Implementation details are hidden from callers.

exception-chaining-example
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
/**
 * Exception chaining across architectural layers
 */
 
// Repository layer - deals with database specifics
class UserRepository {
    async findById(id: string): Promise<User> {
        try {
            const row = await this.database.query(
                'SELECT * FROM users WHERE id = ?', 
                [id]
            );
            
            if (!row) {
                throw new EntityNotFoundError('User', id);
            }
            
            return this.mapToUser(row);
            
        } catch (error) {
            if (error instanceof EntityNotFoundError) {
                throw error;  // Already appropriate abstraction
            }
            
            // Wrap low-level database error in repository-level exception
            // The original error is preserved as 'cause'
            throw new RepositoryError(
                `Failed to fetch user ${id}`,
                'UserRepository.findById',
                { userId: id },
                error as Error  // Preserve original cause
            );
        }
    }
}
 
// Service layer - deals with business logic
class UserService {
    constructor(private repository: UserRepository) {}
    
    async getUser(id: string): Promise<User> {
        try {
            return await this.repository.findById(id);
            
        } catch (error) {
            if (error instanceof EntityNotFoundError) {
                // Translate to service-layer exception
                throw new UserNotFoundError(id, error);
            }
            
            if (error instanceof RepositoryError) {
                // Wrap repository error in service-level exception
                throw new UserServiceError(
                    `Failed to retrieve user`,
                    { userId: id },
                    error  // Chain the repository error
                );
            }
            
            throw error;
        }
    }
}
 
// Controller layer - deals with HTTP concerns
class UserController {
    constructor(private service: UserService) {}
    
    async getUser(req: Request): Promise<Response> {
        try {
            const user = await this.service.getUser(req.params.id);
            return Response.json(user);
            
        } catch (error) {
            if (error instanceof UserNotFoundError) {
                return Response.json(
                    { error: 'User not found' },
                    { status: 404 }
                );
            }
            
            if (error instanceof UserServiceError) {
                // Log the full chain for debugging
                console.error('User retrieval failed:', {
                    message: error.message,
                    cause: error.cause?.message,
                    rootCause: getRootCause(error)?.message
                });
                
                return Response.json(
                    { error: 'Internal server error' },
                    { status: 500 }
                );
            }
            
            throw error;
        }
    }
}
 
// Utility to traverse exception chain
function getRootCause(error: Error): Error {
    let current = error;
    while (current.cause && current.cause instanceof Error) {
        current = current.cause;
    }
    return current;
}

Chain, Don't Lose

When wrapping exceptions, always preserve the original as the 'cause'. Losing the original exception makes debugging nearly impossible. Most languages support exception chaining: Java has the 'Throwable.cause' field, Python uses 'raise ... from', and JavaScript/TypeScript supports 'Error.cause' in newer versions.

Exceptions vs. Return Values: Tradeoffs

Exceptions are not the only way to signal errors. Many languages and paradigms favor using return values (Result types, Option types, error codes) instead. Understanding the tradeoffs helps you choose the right approach for each situation.

Exceptions - Strengths

•Cannot be ignored (propagate automatically)
•Separate error handling from business logic
•Rich information (stack traces, chaining)
•Natural for unrecoverable errors
•Well-suited for deep call stacks
•Type hierarchies enable flexible catching

Exceptions - Weaknesses

•Hidden control flow (hard to trace)
•Performance cost when thrown
•Easy to catch too broadly
•Can mask errors if mishandled
•Not visible in function signatures (usually)
•Breaks referential transparency

Return Values - Strengths

•Explicit in function signatures
•Forces handling at call site
•Predictable control flow
•No performance overhead
•Works well with type systems
•Natural for expected failures

Return Values - Weaknesses

•Can be ignored (unsafe languages)
•Verbose - requires handling everywhere
•Error propagation is manual
•Business logic cluttered with error checks
•Hard to handle deep in call stacks
•Less information than exceptions

Choosing Between Exceptions and Return Values
Scenario	Recommended Approach	Rationale
Configuration missing at startup	Exception	Cannot continue, truly exceptional
User not found in lookup	Return value (null/Option)	Expected outcome, not exceptional
Database connection lost	Exception	Cannot recover locally, need escalation
Validation fails on user input	Return value (Result type)	Expected case, caller should handle
Out of memory	Exception (Error)	Unrecoverable, system-level failure
Operation timeout	Either	Depends on whether caller can retry
Authentication fails	Return value or specific exception	Expected case, needs specific handling

The Guideline

Use exceptions for conditions that should rarely occur, cannot be handled locally, or represent genuine failures. Use return values for conditions that are expected, recoverable, and part of normal operation. When in doubt, ask: 'If this happens frequently, would exception overhead matter?' If yes, use return values.

Summary: Understanding Exceptions

We've built a comprehensive understanding of exceptions as a mechanism for error signaling. This foundation prepares us to decide when to use exceptions versus other approaches.

Key Takeaways:

Core Concepts to Remember

•Exceptions are signals, not problems — They're the fire alarm, not the fire. The mechanism to communicate, not the error itself.
•Exceptions have runtime costs — Zero-cost on the happy path, but expensive when thrown. Reserve for truly exceptional cases.
•Exception constructs work together — try, catch, finally, throw each serve distinct purposes in a complete error handling strategy.
•Hierarchies enable flexible handling — Well-designed exception hierarchies let you catch at the right level of abstraction.
•Chaining preserves information — When crossing layers, wrap exceptions without losing root cause information.
•Exceptions vs returns is a design choice — Choose based on whether the failure is expected, recoverable, and how deep in the call stack it occurs.

What's Next:

With solid understanding of both errors and exceptions, we're ready to explore the crucial question: When should you use exceptions versus other error handling mechanisms? The next page provides a practical framework for making this decision in real-world scenarios.

Page Complete

You now understand exceptions as a mechanism—how they work, their constructs, hierarchies, and tradeoffs. This prepares you to make informed decisions about when and how to use exceptions in your systems.

2 / 4

Loading learning content...

System Design (LLD)Errors vs Exceptions

Errors vs Exceptions: Foundations of Robust Error Handling

LevelIntermediate

Duration60 mins

TopicErrors vs Exceptions

2 / 4

What is an Exception

The Mechanism Behind Error Signaling

What You Will Learn

Defining Exceptions: The Signal, Not the Problem

The Key Distinction:

Concept	Analogy	Role
Error	A fire in a building	The actual problem
Exception	The fire alarm	The mechanism that signals the problem

Just as a fire alarm doesn't cause the fire (it signals its presence), an exception doesn't cause the error (it signals its detection).

Formal Definition:

An exception is a language construct that:

Interrupts normal sequential execution
Transfers control to a designated handler
Carries information about the error condition
Propagates up the call stack if not handled locally

exception-signaling-example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
/**
 * The Error: Invalid account state (business rule violation)
 * The Exception: The thrown Error object that signals this condition
 */
class InsufficientFundsError extends Error {
    constructor(
        public readonly accountId: string,
        public readonly requestedAmount: number,
        public readonly availableBalance: number
    ) {
        super(
            `Insufficient funds in account ${accountId}: ` +
                                        `requested ${requestedAmount}, available ${availableBalance}`
        );
        this.name = 'InsufficientFundsError';
    }
}
 
class BankAccount {
    private balance: number;
    
    constructor(
        private readonly accountId: string, 
        initialBalance: number
    ) {
        this.balance = initialBalance;
    }
    
    /**
     * Attempts to withdraw money from the account.
     * 
     * When an ERROR condition is detected (insufficient funds),
     * an EXCEPTION is thrown to signal this to the caller.
     */
    withdraw(amount: number): void {
        // Detect the error condition
        if (amount > this.balance) {
            // Signal the error by throwing an exception
            // The error IS the insufficient funds condition
            // The exception IS the InsufficientFundsError object
            throw new InsufficientFundsError(
                this.accountId,
                amount,
                this.balance
            );
        }
        
        // Normal execution path
        this.balance -= amount;
    }
}
 
// The exception propagates until caught
function transferFunds(from: BankAccount, to: BankAccount, amount: number): void {
    // If withdraw throws, this function also "throws" (propagates)
    from.withdraw(amount);
    
    // This line only executes if no exception was thrown
    to.deposit(amount);
}

How Exceptions Work: Under the Hood

To use exceptions effectively, we need to understand how they work at the runtime level. This knowledge informs performance considerations and helps us reason about control flow.

The Exception Mechanism:

When an exception is thrown, the runtime performs these steps:

Exception object creation: An object representing the error is instantiated, typically including a message, stack trace, and other context.
Stack unwinding: The runtime searches up the call stack for an exception handler that can handle this exception type.
Handler matching: At each stack frame, the runtime checks if there's a matching catch block. Matching typically follows type hierarchy—a handler for Exception catches its subclasses.
Handler execution: When a matching handler is found, control transfers to it. The stack frames between the throw site and the handler are discarded.
Normal resumption or propagation: After the handler completes, execution continues normally, or the exception is re-thrown to propagate further.

Converting Mermaid diagram...

Performance Implications:

Exception handling involves runtime costs that differ from normal control flow:

Exception Handling Performance Characteristics
Aspect	Normal Path (no exception)	Exception Path
Try block entry	Negligible (register setup)	N/A
Normal execution	Zero overhead in modern runtimes	N/A
Exception creation	N/A	Moderate (object allocation, stack trace capture)
Stack unwinding	N/A	Costly (proportional to stack depth)
Handler execution	N/A	Normal execution cost

Performance Insight

exception-overhead-demonstration
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
/**
 * Demonstrating why exceptions shouldn't be used for control flow
 */
 
// BAD: Using exceptions for expected outcomes
function findUserBad(users: User[], id: string): User {
    const user = users.find(u => u.id === id);
    if (!user) {
        throw new Error("User not found");  // Expected case treated as exception
    }
    return user;
}
 
// Processing 10,000 lookups where 50% are not found:
// - 5,000 exception throws
// - 5,000 stack traces captured
// - 5,000 stack unwinds
// Result: Massive performance degradation
 
// GOOD: Expected outcomes returned normally
function findUserGood(users: User[], id: string): User | null {
    return users.find(u => u.id === id) ?? null;
}
 
// Processing 10,000 lookups where 50% are not found:
// - 10,000 simple returns (null or user)
// - Zero exception overhead
// Result: Optimal performance
 
 
// APPROPRIATE: True exceptions for actual exceptional conditions
function getRequiredConfig(key: string): string {
    const value = process.env[key];
    if (!value) {
        // This IS exceptional: the app cannot function without this config
        // This should happen 0 times in normal operation
        throw new ConfigurationError(`Required config missing: ${key}`);
    }
    return value;
}

Anatomy of Exception Constructs

Most languages provide a standard set of constructs for working with exceptions. Understanding each piece is essential for effective exception handling.

The Core Constructs:

Exception Handling Constructs

•throw / raise: Signals an exception, transferring control to the nearest matching handler. Creates the exception object and initiates stack unwinding.
•try: Defines a protected block of code where exceptions will be caught. Establishes a 'checkpoint' in the stack for exception handling.
•catch / except: Defines a handler for specific exception types. Controls which exceptions are handled and what action to take.
•finally / ensure: Defines cleanup code that runs regardless of whether an exception occurred. Essential for resource management.
•rethrow: Propagates a caught exception to the next handler up the stack. Allows partial handling before escalation.

exception-construct-anatomy
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
/**
 * Comprehensive example showing all exception constructs
 */
class DatabaseConnection {
    private isOpen = false;
    
    open(): void {
        console.log("Opening database connection");
        this.isOpen = true;
    }
    
    close(): void {
        console.log("Closing database connection");
        this.isOpen = false;
    }
    
    execute(query: string): Result {
        if (!this.isOpen) {
            throw new Error("Connection not open");
        }
        // Execute query...
        return { rows: [] };
    }
}
 
async function processTransaction(data: TransactionData): Promise<void> {
    const connection = new DatabaseConnection();
    
    try {
        // TRY block: Protected code where exceptions are monitored
        connection.open();
        
        const result = await validateData(data);
        
        if (!result.isValid) {
            // THROW: Signal an error condition
            throw new ValidationError(
                "Transaction data is invalid",
                result.errors
            );
        }
        
        await connection.execute("BEGIN TRANSACTION");
        await connection.execute(`INSERT INTO transactions...`);
        await connection.execute("COMMIT");
        
    } catch (error) {
        // CATCH block: Handle specific exception types
        
        if (error instanceof ValidationError) {
            // Handle validation errors specifically
            console.error("Validation failed:", error.errors);
            await notifyUser(error.message);
            // Don't rethrow - this is fully handled
            
        } else if (error instanceof DatabaseError) {
            // Handle database errors
            console.error("Database error:", error.message);
            await connection.execute("ROLLBACK").catch(() => {});
            
            // RETHROW: Propagate to caller for further handling
            throw error;
            
        } else {
            // Unknown error - wrap and rethrow
            throw new TransactionError(
                "Unexpected error during transaction",
                { cause: error }
            );
        }
        
    } finally {
        // FINALLY block: Cleanup that ALWAYS runs
        // Runs after try (if no exception)
        // Runs after catch (if exception was caught)
        // Runs even if exception is rethrown
        
        connection.close();  // Resource cleanup guaranteed
        console.log("Transaction processing completed");
    }
}

Finally Block Gotchas

Exception Types and Hierarchies

Common Exception Hierarchy Patterns:

Converting Mermaid diagram...

Key Categories in Exception Hierarchies:

Exception Hierarchy Categories
Category	Examples	Should Catch?	Typical Cause
Errors (Fatal)	OutOfMemoryError, StackOverflow	Usually no	JVM/runtime failure, cannot recover
Unchecked (Runtime)	NullPointer, IllegalArgument	Selectively	Programming bugs, invalid state
Checked (Anticipated)	IOException, SQLException	Yes, required	External failures, expected problems
Custom Business	InsufficientFunds, UserNotFound	Yes, specific	Domain-specific error conditions

exception-hierarchy-design
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
/**
 * Well-designed exception hierarchy for a payment processing system
 */
 
// Base exception for all application errors
abstract class ApplicationError extends Error {
    abstract readonly code: string;
    abstract readonly isRetryable: boolean;
    
    constructor(message: string, public readonly cause?: Error) {
        super(message);
        this.name = this.constructor.name;
        
        // Capture stack trace (V8 engines)
        if (Error.captureStackTrace) {
            Error.captureStackTrace(this, this.constructor);
        }
    }
}
 
// Category: Domain/Business Errors
abstract class DomainError extends ApplicationError {
    readonly isRetryable = false;  // Business errors aren't retryable
}
 
class InsufficientFundsError extends DomainError {
    readonly code = 'INSUFFICIENT_FUNDS';
    
    constructor(
        public readonly accountId: string,
        public readonly required: number,
        public readonly available: number
    ) {
        super(`Account ${accountId} has insufficient funds`);
    }
}
 
class AccountLockedError extends DomainError {
    readonly code = 'ACCOUNT_LOCKED';
    
    constructor(
        public readonly accountId: string,
        public readonly reason: string
    ) {
        super(`Account ${accountId} is locked: ${reason}`);
    }
}
 
// Category: Infrastructure Errors
abstract class InfrastructureError extends ApplicationError {}
 
class DatabaseError extends InfrastructureError {
    readonly code = 'DATABASE_ERROR';
    readonly isRetryable = true;
    
    constructor(message: string, cause?: Error) {
        super(`Database operation failed: ${message}`, cause);
    }
}
 
class NetworkError extends InfrastructureError {
    readonly code = 'NETWORK_ERROR';
    readonly isRetryable = true;
    
    constructor(
        public readonly endpoint: string,
        cause?: Error
    ) {
        super(`Network request to ${endpoint} failed`, cause);
    }
}
 
// Category: Validation Errors
class ValidationError extends ApplicationError {
    readonly code = 'VALIDATION_ERROR';
    readonly isRetryable = false;
    
    constructor(
        message: string,
        public readonly field: string,
        public readonly violations: string[]
    ) {
        super(message);
    }
}
 
 
// Usage: Catch by category for flexible handling
async function processPayment(payment: Payment): Promise<void> {
    try {
        await paymentGateway.process(payment);
        
    } catch (error) {
        if (error instanceof DomainError) {
            // Business rule violation - inform user
            throw new UserFacingError(error.message, error.code);
            
        } else if (error instanceof InfrastructureError && error.isRetryable) {
            // Infrastructure issue - retry
            await retryWithBackoff(() => paymentGateway.process(payment));
            
        } else {
            // Unknown error - escalate
            throw error;
        }
    }
}

Hierarchy Design Principle

Exception Chaining and Wrapping

Why Chain Exceptions?

Benefits of Exception Chaining

•Abstraction preservation: Higher layers deal with domain-appropriate exceptions, not low-level technical details.
•Root cause preservation: The original exception is captured for debugging, not lost.
•Context enrichment: Each layer can add its own context to the error.
•Type safety: Catch blocks can match on the appropriate abstraction level.
•Information hiding: Implementation details are hidden from callers.

exception-chaining-example
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
/**
 * Exception chaining across architectural layers
 */
 
// Repository layer - deals with database specifics
class UserRepository {
    async findById(id: string): Promise<User> {
        try {
            const row = await this.database.query(
                'SELECT * FROM users WHERE id = ?', 
                [id]
            );
            
            if (!row) {
                throw new EntityNotFoundError('User', id);
            }
            
            return this.mapToUser(row);
            
        } catch (error) {
            if (error instanceof EntityNotFoundError) {
                throw error;  // Already appropriate abstraction
            }
            
            // Wrap low-level database error in repository-level exception
            // The original error is preserved as 'cause'
            throw new RepositoryError(
                `Failed to fetch user ${id}`,
                'UserRepository.findById',
                { userId: id },
                error as Error  // Preserve original cause
            );
        }
    }
}
 
// Service layer - deals with business logic
class UserService {
    constructor(private repository: UserRepository) {}
    
    async getUser(id: string): Promise<User> {
        try {
            return await this.repository.findById(id);
            
        } catch (error) {
            if (error instanceof EntityNotFoundError) {
                // Translate to service-layer exception
                throw new UserNotFoundError(id, error);
            }
            
            if (error instanceof RepositoryError) {
                // Wrap repository error in service-level exception
                throw new UserServiceError(
                    `Failed to retrieve user`,
                    { userId: id },
                    error  // Chain the repository error
                );
            }
            
            throw error;
        }
    }
}
 
// Controller layer - deals with HTTP concerns
class UserController {
    constructor(private service: UserService) {}
    
    async getUser(req: Request): Promise<Response> {
        try {
            const user = await this.service.getUser(req.params.id);
            return Response.json(user);
            
        } catch (error) {
            if (error instanceof UserNotFoundError) {
                return Response.json(
                    { error: 'User not found' },
                    { status: 404 }
                );
            }
            
            if (error instanceof UserServiceError) {
                // Log the full chain for debugging
                console.error('User retrieval failed:', {
                    message: error.message,
                    cause: error.cause?.message,
                    rootCause: getRootCause(error)?.message
                });
                
                return Response.json(
                    { error: 'Internal server error' },
                    { status: 500 }
                );
            }
            
            throw error;
        }
    }
}
 
// Utility to traverse exception chain
function getRootCause(error: Error): Error {
    let current = error;
    while (current.cause && current.cause instanceof Error) {
        current = current.cause;
    }
    return current;
}

Chain, Don't Lose

Exceptions vs. Return Values: Tradeoffs

Exceptions - Strengths

•Cannot be ignored (propagate automatically)
•Separate error handling from business logic
•Rich information (stack traces, chaining)
•Natural for unrecoverable errors
•Well-suited for deep call stacks
•Type hierarchies enable flexible catching

Exceptions - Weaknesses

•Hidden control flow (hard to trace)
•Performance cost when thrown
•Easy to catch too broadly
•Can mask errors if mishandled
•Not visible in function signatures (usually)
•Breaks referential transparency

Return Values - Strengths

•Explicit in function signatures
•Forces handling at call site
•Predictable control flow
•No performance overhead
•Works well with type systems
•Natural for expected failures

Return Values - Weaknesses

•Can be ignored (unsafe languages)
•Verbose - requires handling everywhere
•Error propagation is manual
•Business logic cluttered with error checks
•Hard to handle deep in call stacks
•Less information than exceptions

Choosing Between Exceptions and Return Values
Scenario	Recommended Approach	Rationale
Configuration missing at startup	Exception	Cannot continue, truly exceptional
User not found in lookup	Return value (null/Option)	Expected outcome, not exceptional
Database connection lost	Exception	Cannot recover locally, need escalation
Validation fails on user input	Return value (Result type)	Expected case, caller should handle
Out of memory	Exception (Error)	Unrecoverable, system-level failure
Operation timeout	Either	Depends on whether caller can retry
Authentication fails	Return value or specific exception	Expected case, needs specific handling

The Guideline

Summary: Understanding Exceptions

We've built a comprehensive understanding of exceptions as a mechanism for error signaling. This foundation prepares us to decide when to use exceptions versus other approaches.

Key Takeaways:

Core Concepts to Remember

•Exceptions are signals, not problems — They're the fire alarm, not the fire. The mechanism to communicate, not the error itself.
•Exceptions have runtime costs — Zero-cost on the happy path, but expensive when thrown. Reserve for truly exceptional cases.
•Exception constructs work together — try, catch, finally, throw each serve distinct purposes in a complete error handling strategy.
•Hierarchies enable flexible handling — Well-designed exception hierarchies let you catch at the right level of abstraction.
•Chaining preserves information — When crossing layers, wrap exceptions without losing root cause information.
•Exceptions vs returns is a design choice — Choose based on whether the failure is expected, recoverable, and how deep in the call stack it occurs.

What's Next:

Page Complete

2 / 4