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.

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.

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.

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
Copy to clipboard
1class ExternalServiceError extends Error {
2    constructor(message: string) {
3        super(message);
4        this.name = "ExternalServiceError";
5    }
6}
7
8class DataAccessError extends Error {
9    constructor(message: string, public originalError: Error) {
10        super(message);
11        this.name = "DataAccessError";
12    }
13}
14
15function fetchData() {
16    try {
17        // Code to interact with the third-party API
18    } catch (e) {
19        throw new DataAccessError("Failed to retrieve data from external service", e);
20    }
21}

In the above scenario, the DataAccessError masks the details of the ExternalServiceError, shielding the rest of the application while preserving context for debugging.

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
Copy to clipboard
1class OrderProcessingError extends Error {
2    constructor(message: string, public originalError: Error) {
3        super(message);
4        this.name = "OrderProcessingError";
5    }
6}
7
8class InventoryError extends Error {
9    constructor(message: string) {
10        super(message);
11        this.name = "InventoryError";
12    }
13}
14
15class InventoryService {
16    reserveItems(items: string[]): void {
17        if (items.length === 0) {
18            throw new InventoryError("No items in the order to reserve.");
19        }
20        // Reserve logic
21    }
22}
23
24class OrderService {
25    private inventoryService: InventoryService;
26
27    constructor(inventoryService: InventoryService) {
28        this.inventoryService = inventoryService;
29    }
30
31    processOrder(order: { items: string[] }): void {
32        try {
33            this.inventoryService.reserveItems(order.items);
34        } catch (e) {
35            throw new OrderProcessingError("Failed to reserve items", e);
36        }
37    }
38}
39
40// Usage example
41const inventoryService = new InventoryService();
42const orderService = new OrderService(inventoryService);
43
44try {
45    orderService.processOrder({ items: [] });
46} catch (e) {
47    console.error(e.message);
48}

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.

As we conclude this lesson on error handling, remember the importance of designing your code to handle errors gracefully while maintaining the integrity and readability of your codebase. By using strategies like meaningful error propagation and leveraging TypeScript's features such as static typing and custom error classes, you can elevate your programming skills.

Now, you're ready to tackle practice exercises that will reinforce these concepts. Apply what you've learned about error handling in multi-class applications to write cleaner and more robust TypeScript code.

Thank you for your dedication throughout this course. With the tools you’ve acquired, you're well-prepared to write and manage clean, maintainable, and efficient TypeScript code!