Introduction to Error Handling in TypeScript

Welcome to the last lesson of the Clean Code with Multiple Classes course! We've explored numerous aspects of clean code, including class collaboration, dependency management, and the use of polymorphism. Today, we will focus on managing errors across multiple classes — a crucial skill for writing robust and clean TypeScript code. Proper error handling helps prevent the propagation of errors and enhances the reliability and maintainability of software.

Recognizing Common Problems in Error Handling

Handling errors that span across multiple classes can introduce several issues if not done correctly. Some of these include: Loss of Error Context: When errors are caught and re-thrown without adequate information, it makes error diagnosis challenging. Tight Coupling: Poorly managed errors can create strong dependencies between classes, making them harder to refactor or test in isolation. Diminished Readability: When error handling is complex and intertwined with business logic, it can obscure the main purpose of the code. Referencing what we learned in the lesson on class collaboration and coupling, maintaining loose coupling and high cohesion is equally important when dealing with errors.

Best Practices for Multi-Class Error Handling

To manage errors effectively across multiple classes, consider the following best practices: Use Custom Error Classes: Create custom error classes to add specificity and context to errors. This aids debugging and makes the code more expressive. Catch and Propagate Errors with Context: When re-throwing errors, include context-specific information to facilitate debugging. Leverage TypeScript's Static Typing: Use TypeScript's type annotations to ensure better error prediction through compile-time checks. Proper error handling provides clear error reporting without cluttering business logic.

Exploring Design Patterns for Error Management

Certain design patterns can facilitate effective error handling across class boundaries: Error Wrapping: This pattern involves wrapping errors with custom classes that only expose safe and useful error information. This is particularly useful when dealing with external systems. For example, consider a service that interacts with a third-party API: TypeScript class ExternalServiceError extends Error {constructor(message: string) {super(message); this.name = "ExternalServiceError";}} class DataAccessError extends Error {constructor(message: string, public originalError: Error) {super(message); this.name = "DataAccessError";}} function fetchData() {try {// Code to interact with the third-party API} catch (e) {throw new DataAccessError("Failed to retrieve data from external service", e);}} class ExternalServiceError extends Error {constructor(message: string) {super(message); this.name = "ExternalServiceError";}} class DataAccessError extends Error {constructor(message: string, public originalError: Error) {super(message); this.name = "DataAccessError";}} function fetchData() {try {// Code to interact with the third-party API} catch (e) {throw new DataAccessError("Failed to retrieve data from external service", e);}} In the above scenario, the DataAccessError masks the details of the ExternalServiceError, shielding the rest of the application while preserving context for debugging.

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Practical Implementation of Error Propagation

Let’s demonstrate error propagation with a multi-class example. Suppose we have an application that processes orders. We'll focus on how errors are handled as they pass through various layers.

TypeScript

class OrderProcessingError extends Error {
    constructor(message: string, public originalError: Error) {
        super(message);
        this.name = "OrderProcessingError";
    }
}

class InventoryError extends Error {
    constructor(message: string) {
        super(message);
        this.name = "InventoryError";
    }
}

class InventoryService {
    reserveItems(items: string[]): void {
        if (items.length === 0) {
            throw new InventoryError("No items in the order to reserve.");
        }
        // Reserve logic
    }
}

class OrderService {
    private inventoryService: InventoryService;

    constructor(inventoryService: InventoryService) {
        this.inventoryService = inventoryService;
    }

    processOrder(order: { items: string[] }): void {
        try {
            this.inventoryService.reserveItems(order.items);
        } catch (e) {
            throw new OrderProcessingError("Failed to reserve items", e);
        }
    }
}

// Usage example
const inventoryService = new InventoryService();
const orderService = new OrderService(inventoryService);

try {
    orderService.processOrder({ items: [] });
} catch (e) {
    console.error(e.message);
}

class OrderProcessingError extends Error {
    constructor(message: string, public originalError: Error) {
        super(message);
        this.name = "OrderProcessingError";
    }
}

class InventoryError extends Error {
    constructor(message: string) {
        super(message);
        this.name = "InventoryError";
    }
}

class InventoryService {
    reserveItems(items: string[]): void {
        if (items.length === 0) {
            throw new InventoryError("No items in the order to reserve.");
        }
        // Reserve logic
    }
}

class OrderService {
    private inventoryService: InventoryService;

    constructor(inventoryService: InventoryService) {
        this.inventoryService = inventoryService;
    }

    processOrder(order: { items: string[] }): void {
        try {
            this.inventoryService.reserveItems(order.items);
        } catch (e) {
            throw new OrderProcessingError("Failed to reserve items", e);
        }
    }
}

// Usage example
const inventoryService = new InventoryService();
const orderService = new OrderService(inventoryService);

try {
    orderService.processOrder({ items: [] });
} catch (e) {
    console.error(e.message);
}

Explanation:

OrderService calls InventoryService to reserve items.
If reserveItems throws an InventoryError, OrderService catches it and throws an OrderProcessingError, adding context relevant to the business logic of order processing.

This pattern maintains clear boundaries between application layers while ensuring that errors do not lose contextual information when moving across classes.

Introduction to Error Handling in TypeScript