Xử lý lỗi TypeScript: Các mẫu đảm bảo kiểu ngoại lệ

Trong thế giới phát triển phần mềm, nơi các ứng dụng cung cấp năng lượng cho mọi thứ từ các hệ thống tài chính toàn cầu đến tương tác di động hàng ngày, việc xây dựng các hệ thống linh hoạt và chịu lỗi không chỉ là một thực tiễn tốt nhất — đó là một sự cần thiết cơ bản. Mặc dù JavaScript cung cấp một môi trường động và linh hoạt, kiểu dữ liệu lỏng lẻo của nó đôi khi có thể dẫn đến những bất ngờ khi chạy, đặc biệt là khi xử lý lỗi. Đây là nơi TypeScript xuất hiện, đưa việc kiểm tra kiểu tĩnh lên hàng đầu và cung cấp các công cụ mạnh mẽ để tăng cường khả năng dự đoán và bảo trì mã.

Xử lý lỗi là một khía cạnh quan trọng của bất kỳ ứng dụng mạnh mẽ nào. Nếu không có chiến lược rõ ràng, các sự cố bất ngờ có thể dẫn đến hành vi không thể đoán trước, hỏng dữ liệu hoặc thậm chí là lỗi hệ thống hoàn toàn. Khi kết hợp với việc đảm bảo kiểu của TypeScript, xử lý lỗi sẽ chuyển từ một nhiệm vụ mã hóa phòng ngừa thành một phần có cấu trúc, có thể dự đoán và quản lý được trong kiến trúc ứng dụng của bạn.

Hướng dẫn toàn diện này đi sâu vào các sắc thái của việc xử lý lỗi TypeScript, khám phá các mẫu và thực tiễn tốt nhất khác nhau để đảm bảo an toàn kiểu cho ngoại lệ. Chúng ta sẽ đi xa hơn khối try...catch cơ bản, khám phá cách tận dụng các tính năng của TypeScript để xác định, bắt và xử lý lỗi với độ chính xác vượt trội. Cho dù bạn đang xây dựng một ứng dụng doanh nghiệp phức tạp, một dịch vụ web lưu lượng truy cập cao hay một trải nghiệm frontend tiên tiến, việc hiểu các mẫu này sẽ trao quyền cho bạn để viết mã đáng tin cậy, dễ gỡ lỗi và dễ bảo trì hơn cho đối tượng nhà phát triển và người dùng toàn cầu.

Nền tảng: Đối tượng Lỗi của JavaScript và try...catch

Trước khi chúng ta khám phá các cải tiến của TypeScript, điều cần thiết là phải hiểu nền tảng của việc xử lý lỗi trong JavaScript. Cơ chế cốt lõi là đối tượng Error, đóng vai trò là cơ sở cho tất cả các lỗi tích hợp tiêu chuẩn.

Các loại Lỗi Chuẩn trong JavaScript

• Error: Đối tượng lỗi cơ sở chung. Hầu hết các lỗi tùy chỉnh đều kế thừa từ nó.
• TypeError: Cho biết một thao tác đã được thực hiện trên một giá trị có kiểu sai.
• ReferenceError: Được ném ra khi một tham chiếu không hợp lệ được tạo (ví dụ: cố gắng sử dụng một biến chưa được khai báo).
• RangeError: Cho biết một biến số hoặc tham số nằm ngoài phạm vi hợp lệ của nó.
• SyntaxError: Xảy ra khi phân tích cú pháp mã không phải là JavaScript hợp lệ.
• URIError: Được ném ra khi các hàm như encodeURI() hoặc decodeURI() được sử dụng không đúng cách.
• EvalError: Liên quan đến hàm toàn cục eval() (ít phổ biến hơn trong mã hiện đại).

Khối try...catch Cơ bản

Cách cơ bản để xử lý lỗi đồng bộ trong JavaScript (và TypeScript) là sử dụng câu lệnh try...catch:

            function divide(a: number, b: number): number {
    if (b === 0) {
        throw new Error("Division by zero is not allowed.");
    }
    return a / b;
}

try {
    const result = divide(10, 0);
    console.log(`Result: ${result}`);
} catch (error) {
    console.error("An error occurred:", error);
}

// Output:
// An error occurred: Error: Division by zero is not allowed.

            

              
                Copy
              
            
          

Trong JavaScript truyền thống, tham số của khối catch mặc định có kiểu any. Điều này có nghĩa là bạn có thể coi error như bất kỳ thứ gì, dẫn đến các sự cố tiềm ẩn khi chạy nếu bạn mong đợi một hình dạng lỗi cụ thể nhưng lại nhận được thứ gì đó khác (ví dụ: một chuỗi hoặc số đơn giản được ném ra). Thiếu đảm bảo kiểu này có thể làm cho việc xử lý lỗi trở nên mong manh và khó gỡ lỗi.

Sự tiến hóa của TypeScript: Kiểu unknown trong các mệnh đề Catch

Với sự ra mắt của TypeScript 4.4, kiểu của biến mệnh đề catch đã được thay đổi từ any thành unknown. Đây là một cải tiến đáng kể cho việc đảm bảo kiểu. Kiểu unknown buộc các nhà phát triển phải thu hẹp kiểu của lỗi một cách rõ ràng trước khi thao tác với nó. Điều này có nghĩa là bạn không thể chỉ truy cập các thuộc tính như error.message hoặc error.statusCode mà không cần khẳng định hoặc kiểm tra kiểu của error trước. Thay đổi này phản ánh cam kết đối với các đảm bảo kiểu mạnh hơn, ngăn chặn các cạm bẫy phổ biến mà các nhà phát triển giả định sai hình dạng của lỗi.

            try {
    throw "Oops, something went wrong!"; // Throwing a string, which is valid in JS
} catch (error) {
    // In TS 4.4+, 'error' is of type 'unknown'
    // console.log(error.message); // ERROR: 'error' is of type 'unknown'.
}

            

              
                Copy
              
            
          

Sự nghiêm ngặt này là một tính năng, không phải là lỗi. Nó thúc đẩy chúng ta viết logic xử lý lỗi mạnh mẽ hơn, đặt nền móng cho các mẫu đảm bảo kiểu mà chúng ta sẽ khám phá tiếp theo.

Tại sao An toàn Kiểu trong Lỗi lại Quan trọng đối với các Ứng dụng Toàn cầu

Đối với các ứng dụng phục vụ cơ sở người dùng toàn cầu và được phát triển bởi các nhóm quốc tế, việc xử lý lỗi nhất quán và có thể dự đoán được là tối quan trọng. An toàn kiểu trong lỗi cung cấp một số lợi thế rõ rệt:

1. Tăng cường Độ tin cậy và Ổn định: Bằng cách xác định rõ ràng các kiểu lỗi, bạn ngăn chặn các sự cố khi chạy bất ngờ có thể phát sinh từ việc cố gắng truy cập các thuộc tính không tồn tại trên một đối tượng lỗi có định dạng sai. Điều này dẫn đến các ứng dụng ổn định hơn, rất quan trọng đối với các dịch vụ mà thời gian ngừng hoạt động có thể gây tốn kém đáng kể về tài chính hoặc danh tiếng trên các thị trường khác nhau.
2. Cải thiện Trải nghiệm Nhà phát triển (DX) và Khả năng Bảo trì: Khi các nhà phát triển hiểu rõ các lỗi mà một hàm có thể ném ra hoặc trả về, họ có thể viết logic xử lý hiệu quả và tập trung hơn. Điều này làm giảm tải nhận thức, tăng tốc độ phát triển và làm cho mã dễ bảo trì và tái cấu trúc hơn, đặc biệt là trong các nhóm lớn, phân tán trải dài trên các múi giờ và nền văn hóa khác nhau.
3. Logic Xử lý Lỗi Có thể Dự đoán: Lỗi đảm bảo kiểu cho phép kiểm tra toàn diện. Bạn có thể viết các câu lệnh switch hoặc chuỗi if/else if bao gồm tất cả các loại lỗi có thể xảy ra, đảm bảo không có lỗi nào bị bỏ sót. Khả năng dự đoán này rất quan trọng đối với các hệ thống phải tuân thủ các thỏa thuận cấp độ dịch vụ (SLA) nghiêm ngặt hoặc các tiêu chuẩn tuân thủ quy định trên toàn thế giới.
4. Gỡ lỗi và Khắc phục Sự cố Tốt hơn: Các loại lỗi cụ thể với siêu dữ liệu phong phú cung cấp ngữ cảnh vô giá trong quá trình gỡ lỗi. Thay vì một thông báo chung chung "đã xảy ra lỗi", bạn nhận được thông tin chính xác như NetworkError với statusCode: 503, hoặc ValidationError với danh sách các trường không hợp lệ. Sự rõ ràng này giảm đáng kể thời gian dành cho việc chẩn đoán sự cố, một lợi ích lớn cho các nhóm vận hành làm việc trên các địa điểm địa lý đa dạng.
5. Hợp đồng API Rõ ràng: Khi thiết kế API hoặc các mô-đun có thể tái sử dụng, việc nêu rõ các loại lỗi có thể được ném ra trở thành một phần của hợp đồng của hàm. Điều này cải thiện các điểm tích hợp, cho phép các dịch vụ hoặc nhóm khác tương tác với mã của bạn một cách có thể dự đoán và an toàn hơn.
6. Tạo điều kiện Quốc tế hóa Thông báo Lỗi: Với các loại lỗi được xác định rõ ràng, bạn có thể ánh xạ các mã lỗi cụ thể với các thông báo được bản địa hóa cho người dùng ở các ngôn ngữ và văn hóa khác nhau. Một UserNotFoundError có thể hiển thị "User not found" bằng tiếng Anh, "Utilisateur introuvable" bằng tiếng Pháp hoặc "Usuario no encontrado" bằng tiếng Tây Ban Nha, nâng cao trải nghiệm người dùng trên toàn cầu mà không làm thay đổi logic xử lý lỗi cơ bản.

Việc áp dụng an toàn kiểu trong xử lý lỗi là một khoản đầu tư vào tương lai của ứng dụng của bạn, đảm bảo nó vẫn mạnh mẽ, có thể mở rộng và dễ quản lý khi nó phát triển và phục vụ đối tượng người dùng toàn cầu.

Mẫu 1: Kiểm tra Kiểu khi Chạy (Thu hẹp Lỗi unknown)

Do biến khối catch được gán kiểu unknown trong TypeScript 4.4 trở lên, mẫu đầu tiên và cơ bản nhất là thu hẹp kiểu của lỗi trong khối catch. Điều này đảm bảo bạn chỉ truy cập các thuộc tính được đảm bảo sẽ tồn tại trên đối tượng lỗi sau khi kiểm tra.

Sử dụng instanceof Error

Cách phổ biến và đơn giản nhất để thu hẹp lỗi unknown là kiểm tra xem nó có phải là một thể hiện của lớp Error tích hợp sẵn hay không (hoặc một trong các lớp con của nó như TypeError, ReferenceError, v.v.).

            function riskyOperation(): void {
    // Simulate different types of errors
    const rand = Math.random();
    if (rand < 0.3) {
        throw new Error("Generic error occurred!");
    } else if (rand < 0.6) {
        throw new TypeError("Invalid data type provided.");
    } else {
        throw { code: 500, message: "Internal Server Error" }; // Non-Error object
    }
}

try {
    riskyOperation();
} catch (error) {
    if (error instanceof Error) {
        console.error(`Caught an Error object: ${error.message}`);
        // You can also check for specific Error subclasses
        if (error instanceof TypeError) {
            console.error("Specifically, a TypeError was caught.");
        }
    } else if (typeof error === 'string') {
        console.error(`Caught a string error: ${error}`);
    } else if (typeof error === 'object' && error !== null && 'message' in error) {
        // Handle custom objects that have a 'message' property
        console.error(`Caught a custom error object with message: ${(error as { message: string }).message}`);
    } else {
        console.error("An unexpected type of error occurred:", error);
    }
}

            

              
                Copy
              
            
          

Cách tiếp cận này cung cấp sự an toàn kiểu cơ bản, cho phép bạn truy cập các thuộc tính message và name của các đối tượng Error tiêu chuẩn. Tuy nhiên, đối với các tình huống lỗi cụ thể hơn, bạn sẽ muốn có thông tin phong phú hơn.

Trình bảo vệ Kiểu Tùy chỉnh cho Đối tượng Lỗi Cụ thể

Thông thường, ứng dụng của bạn sẽ xác định các cấu trúc lỗi tùy chỉnh của riêng mình, có thể chứa mã lỗi cụ thể, mã định danh duy nhất hoặc siêu dữ liệu bổ sung. Để truy cập an toàn các thuộc tính tùy chỉnh này, bạn có thể tạo các trình bảo vệ kiểu do người dùng định nghĩa.

            // 1. Define custom error interfaces/types
interface NetworkError {
    name: "NetworkError";
    message: string;
    statusCode: number;
    url: string;
}

interface ValidationError {
    name: "ValidationError";
    message: string;
    fields: { [key: string]: string };
}

// 2. Create type guards for each custom error
function isNetworkError(error: unknown): error is NetworkError {
    return (
        typeof error === 'object' &&
        error !== null &&
        'name' in error &&
        (error as { name: string }).name === "NetworkError" &&
        'message' in error &&
        'statusCode' in error &&
        'url' in error
    );
}

function isValidationError(error: unknown): error is ValidationError {
    return (
        typeof error === 'object' &&
        error !== null &&
        'name' in error &&
        (error as { name: string }).name === "ValidationError" &&
        'message' in error &&
        'fields' in error &&
        typeof (error as { fields: unknown }).fields === 'object'
    );
}

// 3. Example usage in a 'try...catch' block
function fetchData(url: string): Promise<any> {
    return new Promise((resolve, reject) => {
        // Simulate an API call that might throw different errors
        const rand = Math.random();
        if (rand < 0.4) {
            reject(new Error("Something unexpected happened."));
        } else if (rand < 0.7) {
            reject({ 
                name: "NetworkError", 
                message: "Failed to fetch data", 
                statusCode: 503, 
                url 
            } as NetworkError);
        } else {
            reject({ 
                name: "ValidationError", 
                message: "Invalid input data", 
                fields: { 'email': 'Invalid format' } 
            } as ValidationError);
        }
    });
}

async function processData() {
    const url = "https://api.example.com/data";
    try {
        const data = await fetchData(url);
        console.log("Data fetched successfully:", data);
    } catch (error: unknown) {
        if (isNetworkError(error)) {
            console.error(`Network Error from ${error.url}: ${error.message} (Status: ${error.statusCode})`);
            // Specific handling for network issues, e.g., retry logic or user notification
        } else if (isValidationError(error)) {
            console.error(`Validation Error: ${error.message}`);
            console.error("Invalid fields:", error.fields);
            // Specific handling for validation errors, e.g., display errors next to form fields
        } else if (error instanceof Error) {
            console.error(`Standard Error: ${error.message}`);
        } else {
            console.error("An unknown or unexpected error type occurred:", error);
            // Fallback for truly unexpected errors
        }
    }
}

processData();

            

              
                Copy
              
            
          

Mẫu này làm cho logic xử lý lỗi của bạn trở nên mạnh mẽ và dễ đọc hơn đáng kể. Nó buộc bạn phải xem xét và xử lý rõ ràng các tình huống lỗi khác nhau, điều này rất quan trọng để xây dựng các ứng dụng có thể bảo trì được.

Mẫu 2: Các Lớp Lỗi Tùy chỉnh

Trong khi các trình bảo vệ kiểu trên các interface hữu ích, một phương pháp có cấu trúc và hướng đối tượng hơn là định nghĩa các lớp lỗi tùy chỉnh. Mẫu này cho phép bạn tận dụng tính kế thừa, tạo ra một hệ thống phân cấp các loại lỗi cụ thể có thể được bắt và xử lý với độ chính xác bằng cách sử dụng các kiểm tra instanceof, tương tự như các lỗi JavaScript tích hợp sẵn nhưng với các thuộc tính tùy chỉnh của riêng bạn.

Kế thừa Lớp Error Tích hợp sẵn

Thực tiễn tốt nhất cho các lỗi tùy chỉnh trong TypeScript (và JavaScript) là kế thừa lớp Error cơ sở. Điều này đảm bảo rằng các lỗi tùy chỉnh của bạn giữ lại các thuộc tính như message và stack, rất quan trọng cho việc gỡ lỗi và ghi nhật ký.

            // Base Custom Error
class CustomApplicationError extends Error {
    constructor(message: string, public code: string = 'GENERIC_ERROR') {
        super(message);
        this.name = this.constructor.name; // Sets the error name to the class name
        // Preserve stack trace for better debugging
        if (Error.captureStackTrace) {
            Error.captureStackTrace(this, this.constructor);
        }
    }
}

// Specific Custom Errors
class DatabaseConnectionError extends CustomApplicationError {
    constructor(message: string, public databaseName: string, public connectionString?: string) {
        super(message, 'DB_CONN_ERROR');
    }
}

class UserAuthenticationError extends CustomApplicationError {
    constructor(message: string, public userId?: string, public reason: 'INVALID_CREDENTIALS' | 'SESSION_EXPIRED' | 'FORBIDDEN' = 'INVALID_CREDENTIALS') {
        super(message, 'AUTH_ERROR');
    }
}

class DataValidationFailedError extends CustomApplicationError {
    constructor(message: string, public invalidFields: { [key: string]: string }) {
        super(message, 'VALIDATION_ERROR');
    }
}

            

              
                Copy
              
            
          

Lợi ích của các Lớp Lỗi Tùy chỉnh

1. Ý nghĩa Ngữ nghĩa: Tên lớp lỗi cung cấp cái nhìn sâu sắc ngay lập tức về bản chất của vấn đề (ví dụ: DatabaseConnectionError rõ ràng chỉ ra sự cố cơ sở dữ liệu).
2. Khả năng mở rộng: Bạn có thể thêm các thuộc tính cụ thể vào mỗi loại lỗi (ví dụ: statusCode, userId, fields) có liên quan đến ngữ cảnh lỗi cụ thể đó, làm phong phú thêm thông tin lỗi để gỡ lỗi và xử lý.
3. Nhận dạng Dễ dàng với instanceof: Bắt và phân biệt giữa các lỗi tùy chỉnh khác nhau trở nên đơn giản bằng cách sử dụng instanceof, cho phép logic xử lý lỗi chính xác.
4. Khả năng Bảo trì: Việc tập trung hóa các định nghĩa lỗi giúp mã của bạn dễ hiểu và quản lý hơn. Nếu các thuộc tính của lỗi thay đổi, bạn cập nhật một định nghĩa lớp.
5. Hỗ trợ Công cụ: IDE và trình kiểm tra mã thường có thể cung cấp các đề xuất và cảnh báo tốt hơn khi làm việc với các lớp lỗi riêng biệt.

Xử lý các Lớp Lỗi Tùy chỉnh

            function performDatabaseOperation(query: string): any {
    const rand = Math.random();
    if (rand < 0.4) {
        throw new DatabaseConnectionError("Failed to connect to primary DB", "users_db");
    } else if (rand < 0.7) {
        throw new UserAuthenticationError("User session expired", "user123", 'SESSION_EXPIRED');
    } else {
        throw new DataValidationFailedError("User input invalid", { 'name': 'Name is too short', 'email': 'Invalid email format' });
    }
}

try {
    performDatabaseOperation("SELECT * FROM users");
} catch (error: unknown) {
    if (error instanceof DatabaseConnectionError) {
        console.error(`Database Error: ${error.message}. DB: ${error.databaseName}. Code: ${error.code}`);
        // Logic to attempt reconnect or notify ops team
    } else if (error instanceof UserAuthenticationError) {
        console.warn(`Authentication Error (${error.reason}): ${error.message}. User ID: ${error.userId || 'N/A'}`);
        // Logic to redirect to login page or refresh token
    } else if (error instanceof DataValidationFailedError) {
        console.error(`Validation Error: ${error.message}. Invalid fields: ${JSON.stringify(error.invalidFields)}`);
        // Logic to display validation messages to the user
    } else if (error instanceof Error) {
        console.error(`An unexpected standard error occurred: ${error.message}`);
    } else {
        console.error("A truly unexpected error occurred:", error);
    }
}

            

              
                Copy
              
            
          

Sử dụng các lớp lỗi tùy chỉnh nâng cao đáng kể chất lượng xử lý lỗi của bạn. Nó cho phép bạn xây dựng các hệ thống quản lý lỗi tinh vi vừa mạnh mẽ vừa dễ suy luận, đặc biệt có giá trị đối với các ứng dụng quy mô lớn với logic nghiệp vụ phức tạp.

Mẫu 3: Mẫu Monad Kết quả/Either (Xử lý Lỗi Rõ ràng)

Trong khi try...catch với các lớp lỗi tùy chỉnh cung cấp khả năng xử lý mạnh mẽ cho các ngoại lệ, một số hệ thống lập trình hàm cho rằng các ngoại lệ làm gián đoạn luồng kiểm soát bình thường và có thể làm cho mã khó suy luận hơn, đặc biệt là khi xử lý các hoạt động không đồng bộ. Mẫu "Kết quả" hoặc "Either" monad cung cấp một giải pháp thay thế bằng cách làm cho thành công và thất bại trở nên rõ ràng trong kiểu trả về của hàm, buộc người gọi phải xử lý cả hai kết quả mà không dựa vào `try/catch` để điều khiển luồng.

Monad Kết quả/Either là gì?

Thay vì ném ra một lỗi, một hàm có thể thất bại sẽ trả về một kiểu đặc biệt (thường được gọi là Result hoặc Either) gói gọn giá trị thành công (Ok hoặc Right) hoặc lỗi (Err hoặc Left). Mẫu này phổ biến trong các ngôn ngữ như Rust (Result<T, E>) và Scala (Either<L, R>).

Ý tưởng cốt lõi là chính kiểu trả về cho bạn biết rằng hàm có hai kết quả có thể xảy ra và hệ thống kiểu của TypeScript đảm bảo bạn xử lý cả hai.

Triển khai Kiểu Result Đơn giản

            type Result<T, E> = { success: true; value: T } | { success: false; error: E };

// Helper functions to create Ok and Err results
const ok = <T, E>(value: T): Result<T, E> => ({ success: true, value });
const err = <T, E>(error: E): Result<T, E> => ({ success: false, error });

interface User {
    id: string;
    name: string;
    email: string;
}

// Custom errors for this pattern (can still use classes)
class UserNotFoundError extends Error {
    constructor(userId: string) {
        super(`User with ID '${userId}' not found.`);
        this.name = 'UserNotFoundError';
    }
}

class DatabaseReadError extends Error {
    constructor(message: string, public details?: string) {
        super(message);
        this.name = 'DatabaseReadError';
    }
}

// Function that returns a Result type
function getUserById(id: string): Result<User, UserNotFoundError | DatabaseReadError> {
    // Simulate database operation
    const rand = Math.random();

    if (rand < 0.3) {
        return err(new UserNotFoundError(id)); // Return an error result
    } else if (rand < 0.6) {
        return err(new DatabaseReadError("Failed to read from DB", "Connection timed out")); // Return a database error
    } else {
        return ok({
            id: id,
            name: "John Doe",
            email: `john.${id}@example.com`
        }); // Return a success result
    }
}

// Consuming the Result type
const userResult = getUserById("user-123");

if (userResult.success) {
    console.log(`User found: ${userResult.value.name}, Email: ${userResult.value.email}`);
} else {
    // TypeScript knows userResult.error is of type UserNotFoundError | DatabaseReadError
    if (userResult.error instanceof UserNotFoundError) {
        console.error(`Application Error: ${userResult.error.message}`);
        // Logic for user not found, e.g., display a message to the user
    } else if (userResult.error instanceof DatabaseReadError) {
        console.error(`System Error: ${userResult.error.message}. Details: ${userResult.error.details}`);
        // Logic for database issue, e.g., retry or alert system administrators
    } else {
        // Exhaustive check or fallback for other potential errors
        console.error("An unexpected error occurred:", userResult.error);
    }
}

            

              
                Copy
              
            
          

Mẫu này có thể đặc biệt mạnh mẽ khi nối các hoạt động có thể thất bại, vì bạn có thể sử dụng map, flatMap (hoặc andThen) và các cấu trúc chức năng khác để xử lý Result mà không cần kiểm tra if/else rõ ràng ở mỗi bước, trì hoãn việc xử lý lỗi đến một điểm duy nhất.

Lợi ích của Mẫu Kết quả

1. Xử lý Lỗi Rõ ràng: Các hàm khai báo rõ ràng các lỗi mà chúng có thể trả về trong chữ ký kiểu của chúng, buộc người gọi phải thừa nhận và xử lý tất cả các trạng thái lỗi có thể xảy ra. Điều này loại bỏ các ngoại lệ "bị lãng quên".
2. Tính Minh bạch Tham chiếu: Bằng cách tránh các ngoại lệ làm cơ chế điều khiển luồng, các hàm trở nên có thể dự đoán và dễ kiểm tra hơn.
3. Khả năng Đọc Cải thiện: Luồng mã cho thành công và thất bại được phân định rõ ràng, giúp theo dõi logic dễ dàng hơn.
4. Khả năng Kết hợp: Các kiểu kết quả kết hợp tốt với các kỹ thuật lập trình hàm, cho phép truyền và chuyển đổi lỗi một cách thanh lịch.
5. Không cần Mã mẫu try...catch: Trong nhiều trường hợp, mẫu này có thể giảm nhu cầu về các khối try...catch, đặc biệt là khi kết hợp nhiều hoạt động có thể bị lỗi.

Cân nhắc và Đánh đổi

• Sự dài dòng: Có thể dài dòng đối với các hoạt động đơn giản hoặc khi không tận dụng hiệu quả các cấu trúc chức năng.
• Đường cong Học tập: Các nhà phát triển mới làm quen với lập trình hàm hoặc monad có thể thấy mẫu này phức tạp lúc đầu.
• Hoạt động Không đồng bộ: Mặc dù có thể áp dụng được, việc tích hợp với mã không đồng bộ dựa trên Promise hiện có đòi hỏi phải đóng gói hoặc chuyển đổi cẩn thận. Các thư viện như neverthrow hoặc fp-ts cung cấp các triển khai `Either`/`Result` phức tạp hơn, được tùy chỉnh cho TypeScript, thường có hỗ trợ không đồng bộ tốt hơn.

Mẫu Kết quả/Either là một lựa chọn tuyệt vời cho các ứng dụng ưu tiên xử lý lỗi rõ ràng, thuần chức năng và tập trung mạnh vào an toàn kiểu trên tất cả các luồng thực thi. Nó đặc biệt phù hợp với các hệ thống quan trọng mà mọi chế độ lỗi có thể xảy ra phải được tính đến rõ ràng.

Mẫu 4: Chiến lược Xử lý Lỗi Tập trung

Trong khi các khối `try...catch` riêng lẻ và các loại Kết quả xử lý các lỗi cục bộ, các ứng dụng lớn hơn, đặc biệt là những ứng dụng phục vụ cơ sở người dùng toàn cầu, được hưởng lợi rất nhiều từ các chiến lược xử lý lỗi tập trung. Các chiến lược này đảm bảo báo cáo, ghi nhật ký và phản hồi người dùng nhất quán trên toàn bộ hệ thống, bất kể lỗi phát sinh từ đâu.

Trình xử lý Lỗi Toàn cục

Tập trung hóa việc xử lý lỗi cho phép bạn:

• Ghi nhật ký lỗi nhất quán vào hệ thống giám sát (ví dụ: Sentry, Datadog).
• Cung cấp các thông báo lỗi chung, thân thiện với người dùng cho các lỗi không xác định.
• Xử lý các mối quan tâm trên toàn ứng dụng như gửi thông báo, hoàn tác giao dịch hoặc kích hoạt bộ ngắt mạch.
• Đảm bảo PII (Thông tin nhận dạng cá nhân) hoặc dữ liệu nhạy cảm không bị tiết lộ trong thông báo lỗi cho người dùng hoặc nhật ký vi phạm các quy định về quyền riêng tư dữ liệu (ví dụ: GDPR, CCPA).

Backend (Node.js/Express) Ví dụ

Trong ứng dụng Node.js Express, bạn có thể định nghĩa một middleware xử lý lỗi để bắt tất cả các lỗi do các route và middleware khác của bạn ném ra. Middleware này phải là middleware cuối cùng được đăng ký.

            import express, { Request, Response, NextFunction } from 'express';

// Assume these are our custom error classes
class APIError extends Error {
    constructor(message: string, public statusCode: number = 500) {
        super(message);
        this.name = 'APIError';
    }
}

class UnauthorizedError extends APIError {
    constructor(message: string = 'Unauthorized') {
        super(message, 401);
        this.name = 'UnauthorizedError';
    }
}

class BadRequestError extends APIError {
    constructor(message: string = 'Bad Request') {
        super(message, 400);
        this.name = 'BadRequestError';
    }
}

const app = express();

app.get('/api/users/:id', (req: Request, res: Response, next: NextFunction) => {
    const userId = req.params.id;
    if (userId === 'admin') {
        return next(new UnauthorizedError('Access denied for admin user.'));
    }
    if (!/^[a-z0-9]+$/.test(userId)) {
        return next(new BadRequestError('Invalid user ID format.'));
    }

    // Simulate a successful operation or another unexpected error
    const rand = Math.random();
    if (rand < 0.5) {
        // Successfully fetch user
        res.json({ id: userId, name: 'Test User' });
    } else {
        // Simulate an unexpected internal error
        next(new Error('Failed to retrieve user data due to an unexpected issue.'));
    }
});

// Type-safe error handling middleware
app.use((err: unknown, req: Request, res: Response, next: NextFunction) => {
    // Log the error for internal monitoring
    console.error(`[ERROR] ${new Date().toISOString()} - ${req.method} ${req.originalUrl} -`, err);

    if (err instanceof APIError) {
        // Specific handling for known API errors
        return res.status(err.statusCode).json({
            status: 'error',
            message: err.message,
            code: err.name // Or a specific application-defined error code
        });
    } else if (err instanceof Error) {
        // Generic handling for unexpected standard errors
        return res.status(500).json({
            status: 'error',
            message: 'An unexpected server error occurred.',
            // In production, avoid exposing detailed internal error messages to clients
            detail: process.env.NODE_ENV === 'development' ? err.message : undefined
        });
    } else {
        // Fallback for truly unknown error types
        return res.status(500).json({
            status: 'error',
            message: 'An unknown server error occurred.',
            detail: process.env.NODE_ENV === 'development' ? String(err) : undefined
        });
    }
});

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
    console.log(`Server running on port ${PORT}`);
});

// Example cURL commands:
// curl http://localhost:3000/api/users/admin
// curl http://localhost:3000/api/users/invalid-id!
// curl http://localhost:3000/api/users/valid-id

            

              
                Copy
              
            
          

Frontend (React) Ví dụ: Error Boundaries

Trong các framework frontend như React, Error Boundaries cung cấp một cách để bắt các lỗi JavaScript ở bất kỳ đâu trong cây thành phần con của chúng, ghi nhật ký các lỗi đó và hiển thị một giao diện người dùng dự phòng thay vì làm sập toàn bộ ứng dụng. TypeScript giúp định nghĩa các props và trạng thái cho các ranh giới này và kiểm tra kiểu cho đối tượng lỗi.

            import React, { Component, ErrorInfo, ReactNode } from 'react';

interface ErrorBoundaryProps {
    children: ReactNode;
    fallback?: ReactNode; // Optional custom fallback UI
}

interface ErrorBoundaryState {
    hasError: boolean;
    error: Error | null;
    errorInfo: ErrorInfo | null;
}

class AppErrorBoundary extends Component<ErrorBoundaryProps, ErrorBoundaryState> {
    public state: ErrorBoundaryState = {
        hasError: false,
        error: null,
        errorInfo: null,
    };

    // This static method is called after an error has been thrown by a descendant component.
    static getDerivedStateFromError(_: Error): ErrorBoundaryState {
        // Update state so the next render will show the fallback UI.
        return { hasError: true, error: _, errorInfo: null };
    }

    // This method is called after an error has been thrown by a descendant component.
    componentDidCatch(error: Error, errorInfo: ErrorInfo) {
        // You can also log the error to an error reporting service here
        console.error("Uncaught error in AppErrorBoundary:", error, errorInfo);
        this.setState({ errorInfo: errorInfo, error: error });
    }

    public render() {
        if (this.state.hasError) {
            // You can render any custom fallback UI
            if (this.props.fallback) {
                return this.props.fallback;
            }
            return (
                <div style={{ padding: '20px', border: '1px solid red', borderRadius: '5px' }}>
                    <h2>Oops! Something went wrong.</h2>
                    <p>We're sorry for the inconvenience. Please try refreshing the page or contact support.</p>
                    {this.state.error && (
                        <details style={{ whiteSpace: 'pre-wrap', color: '#666' }}>
                            <summary>Error Details</summary>
                            <p>{this.state.error.message}</p>
                            {this.state.errorInfo && (
                                <p>Component Stack:<br/>{this.state.errorInfo.componentStack}</p>
                            )}
                        </details>
                    )}
                </div>
            );
        }

        return this.props.children;
    }
}

// How to use it:
// function App() {
//   return (
//     <AppErrorBoundary>
//       <SomePotentiallyFailingComponent />
//     </AppErrorBoundary>
//   );
// }

            

              
                Copy
              
            
          

Phân biệt Lỗi Vận hành và Lỗi Lập trình

Một khía cạnh quan trọng của việc xử lý lỗi tập trung là phân biệt giữa hai loại lỗi chính:

• Lỗi Vận hành: Đây là các sự cố có thể dự đoán được có thể xảy ra trong quá trình hoạt động bình thường, thường nằm ngoài logic cốt lõi của ứng dụng. Ví dụ bao gồm lỗi thời gian chờ mạng, lỗi kết nối cơ sở dữ liệu, đầu vào người dùng không hợp lệ, tệp không tìm thấy hoặc giới hạn tốc độ. Những lỗi này nên được xử lý một cách nhẹ nhàng, thường dẫn đến các thông báo thân thiện với người dùng hoặc logic thử lại cụ thể. Chúng thường không chỉ ra lỗi trong mã của bạn. Các lớp lỗi tùy chỉnh với mã lỗi cụ thể rất hữu ích cho những lỗi này.
• Lỗi Lập trình: Đây là các lỗi trong mã của bạn. Ví dụ bao gồm `ReferenceError` (sử dụng một biến chưa được xác định), `TypeError` (gọi một phương thức trên `null`) hoặc các lỗi logic dẫn đến các trạng thái bất ngờ. Những lỗi này thường không thể phục hồi khi chạy và yêu cầu sửa mã. Trình xử lý lỗi toàn cục nên ghi nhật ký chúng một cách toàn diện và có thể kích hoạt khởi động lại ứng dụng hoặc cảnh báo cho nhóm phát triển.

Bằng cách phân loại lỗi, trình xử lý tập trung của bạn có thể quyết định có nên hiển thị thông báo lỗi chung, cố gắng phục hồi hay leo thang vấn đề cho các nhà phát triển. Sự phân biệt này rất quan trọng để duy trì một ứng dụng lành mạnh và phản hồi trên các môi trường đa dạng.

Thực tiễn Tốt nhất cho Xử lý Lỗi Đảm bảo Kiểu

Để tối đa hóa lợi ích của TypeScript trong chiến lược xử lý lỗi của bạn, hãy xem xét các thực tiễn tốt nhất sau:

1. Luôn Thu hẹp unknown trong các Khối catch: Kể từ TypeScript 4.4 trở lên, biến catch là unknown. Luôn thực hiện kiểm tra kiểu khi chạy (ví dụ: instanceof Error, trình bảo vệ kiểu tùy chỉnh) để truy cập an toàn các thuộc tính lỗi. Điều này ngăn chặn các lỗi chạy phổ biến.
2. Thiết kế các Lớp Lỗi Tùy chỉnh có Ý nghĩa: Kế thừa lớp Error cơ sở để tạo các loại lỗi cụ thể, có ý nghĩa ngữ nghĩa. Bao gồm các thuộc tính có liên quan đến ngữ cảnh cụ thể (ví dụ: statusCode, errorCode, invalidFields, userId) để hỗ trợ gỡ lỗi và xử lý.
3. Rõ ràng về Hợp đồng Lỗi: Tài liệu hóa các lỗi mà một hàm có thể ném ra hoặc trả về. Nếu sử dụng mẫu Kết quả, điều này được thực thi bởi chữ ký kiểu trả về. Đối với `try/catch`, các nhận xét JSDoc rõ ràng hoặc các chữ ký hàm truyền đạt các ngoại lệ tiềm ẩn là có giá trị.
4. Ghi nhật ký Lỗi Toàn diện: Sử dụng phương pháp ghi nhật ký có cấu trúc. Chụp toàn bộ dấu vết ngăn xếp lỗi, cùng với bất kỳ thuộc tính lỗi tùy chỉnh nào và thông tin ngữ cảnh (ví dụ: ID yêu cầu, ID người dùng, dấu thời gian, môi trường). Đối với các ứng dụng quan trọng, hãy tích hợp với một hệ thống ghi nhật ký và giám sát tập trung (ví dụ: ELK Stack, Splunk, DataDog, Sentry).
5. Tránh Ném các Kiểu string hoặc object Chung chung: Mặc dù JavaScript cho phép điều này, việc ném chuỗi thô, số hoặc đối tượng thuần túy làm cho việc xử lý lỗi đảm bảo kiểu trở nên không thể và dẫn đến mã kém bền vững. Luôn ném các thể hiện của Error hoặc các lớp lỗi tùy chỉnh.
6. Tận dụng never cho Kiểm tra Toàn diện: Khi làm việc với một hợp nhất các loại lỗi tùy chỉnh (ví dụ: trong một câu lệnh switch hoặc một chuỗi các khối if/else if), hãy sử dụng trình bảo vệ kiểu dẫn đến kiểu `never` cho khối else cuối cùng. Điều này đảm bảo rằng nếu một loại lỗi mới được giới thiệu, TypeScript sẽ gắn cờ trường hợp chưa được xử lý.

            type SpecificError = DatabaseConnectionError | UserAuthenticationError | DataValidationFailedError;

function handleSpecificError(error: SpecificError) {
    if (error instanceof DatabaseConnectionError) {
        // ...
    } else if (error instanceof UserAuthenticationError) {
        // ...
    } else if (error instanceof DataValidationFailedError) {
        // ...
    } else {
        // This line should ideally be unreachable. If it is, a new error type was added
        // to SpecificError but not handled here, causing a TS error.
        const exhaustiveCheck: never = error; // TypeScript will flag this if 'error' is not 'never'
    }
}

            

              
                Copy
              
            
          

7. Dịch Lỗi cho Trải nghiệm Người dùng: Thông báo lỗi nội bộ dành cho nhà phát triển. Đối với người dùng cuối, hãy dịch các lỗi kỹ thuật thành các thông báo rõ ràng, có thể hành động và phù hợp về mặt văn hóa. Hãy xem xét sử dụng mã lỗi ánh xạ với các thông báo được bản địa hóa để hỗ trợ quốc tế hóa.
8. Phân biệt Lỗi Có thể Khôi phục và Lỗi Không thể Khôi phục: Thiết kế logic xử lý lỗi của bạn để phân biệt giữa các lỗi có thể thử lại hoặc tự sửa chữa (ví dụ: sự cố mạng) và những lỗi chỉ ra lỗi ứng dụng nghiêm trọng (ví dụ: lỗi lập trình chưa được xử lý).
9. Kiểm tra các Luồng Lỗi của Bạn: Giống như bạn kiểm tra các luồng hạnh phúc, hãy kiểm tra kỹ các luồng lỗi của bạn. Đảm bảo rằng ứng dụng của bạn xử lý các điều kiện lỗi đã biết một cách nhẹ nhàng và hoạt động sai một cách có thể dự đoán được khi xảy ra các điều kiện không mong muốn.

Việc tuân thủ các thực tiễn này sẽ nâng cao các ứng dụng TypeScript của bạn từ chỉ đơn thuần là chức năng lên mạnh mẽ, đáng tin cậy và dễ bảo trì, có khả năng phục vụ đối tượng người dùng đa dạng trên toàn thế giới.

Các Cạm bẫy Phổ biến và Cách Tránh chúng

Ngay cả với ý định tốt nhất, các nhà phát triển có thể mắc phải những cái bẫy phổ biến khi xử lý lỗi trong TypeScript. Nhận thức được những cạm bẫy này có thể giúp bạn tránh xa chúng.

1. Bỏ qua Kiểu unknown trong các Khối catch:

   Cạm bẫy: Giả định trực tiếp kiểu của error trong khối catch mà không thu hẹp.

               try {
       throw new Error("Oops");
   } catch (error) {
       // Type 'unknown' is not assignable to type 'Error'.
       // Property 'message' does not exist on type 'unknown'.
       // console.error(error.message); // This will be a TypeScript error!
   }
   
               
   
                 
                   Copy
                 
               
             

   Cách tránh: Luôn sử dụng instanceof Error hoặc các trình bảo vệ kiểu tùy chỉnh để thu hẹp kiểu.

               try {
       throw new Error("Oops");
   } catch (error: unknown) {
       if (error instanceof Error) {
           console.error(error.message);
       } else {
           console.error("A non-Error type was thrown:", error);
       }
   }
   
               
   
                 
                   Copy
                 
               
             

2. Tổng quát hóa Khối catch Quá mức:

   Cạm bẫy: Bắt Error khi bạn chỉ định xử lý một lỗi tùy chỉnh cụ thể. Điều này có thể che giấu các sự cố tiềm ẩn.

               // Assume a custom APIError
   class APIError extends Error { /* ... */ }
   
   function fetchData() {
       throw new APIError("Failed to fetch");
   }
   
   function processData() {
       try {
           fetchData();
       } catch (error: unknown) {
           // This catches APIError, but also *any* other Error that might be thrown
           // by fetchData or other code in the try block, potentially masking bugs.
           if (error instanceof Error) {
               console.error("Caught a generic error:", error.message);
           }
       }
   }
   
               
   
                 
                   Copy
                 
               
             

   Cách tránh: Cụ thể nhất có thể. Nếu bạn mong đợi các lỗi tùy chỉnh cụ thể, hãy bắt chúng trước. Sử dụng một giải pháp dự phòng cho Error hoặc unknown chung chung.

               try {
       fetchData();
   } catch (error: unknown) {
       if (error instanceof APIError) {
           // Handle APIError specifically
           console.error("API Error:", error.message);
       } else if (error instanceof Error) {
           // Handle other standard errors
           console.error("Unexpected standard Error:", error.message);
       } else {
           // Handle truly unknown errors
           console.error("Truly unexpected error:", error);
       }
   }
   
               
   
                 
                   Copy
                 
               
             

3. Thiếu Thông báo Lỗi và Ngữ cảnh Cụ thể:

   Cạm bẫy: Ném các thông báo chung chung như "An error occurred" mà không cung cấp ngữ cảnh hữu ích, làm cho việc gỡ lỗi trở nên khó khăn.

               throw new Error("Something went wrong."); // Not very helpful
   
               
   
                 
                   Copy
                 
               
             

   Cách tránh: Đảm bảo thông báo lỗi mô tả và bao gồm dữ liệu liên quan (ví dụ: giá trị tham số, đường dẫn tệp, ID). Các lớp lỗi tùy chỉnh với các thuộc tính cụ thể rất hữu ích cho việc này.

               throw new DatabaseConnectionError("Failed to connect to DB", "users_db", "mongodb://localhost:27017");
   
               
   
                 
                   Copy
                 
               
             

4. Không Phân biệt giữa Lỗi Hướng đến Người dùng và Lỗi Nội bộ:

   Cạm bẫy: Hiển thị các thông báo lỗi kỹ thuật thô (ví dụ: dấu vết ngăn xếp, lỗi truy vấn cơ sở dữ liệu) trực tiếp cho người dùng cuối.

               // Bad: Exposing internal details to the user
   catch (error: unknown) {
       if (error instanceof Error) {
           res.status(500).send(`<h1>Server Error</h1><p>${error.stack}</p>`);
       }
   }
   
               
   
                 
                   Copy
                 
               
             

   Cách tránh: Tập trung hóa việc xử lý lỗi để chặn các lỗi nội bộ và dịch chúng thành các thông báo thân thiện với người dùng, được bản địa hóa. Chỉ ghi nhật ký chi tiết kỹ thuật cho các nhà phát triển.

               // Good: User-friendly message for client, detailed log for developers
   catch (error: unknown) {
       // ... logging for developers ...
       res.status(500).send("<h1>We're sorry!</h1><p>An unexpected error occurred. Please try again later.</p>");
   }
   
               
   
                 
                   Copy
                 
               
             

5. Sửa đổi Đối tượng Lỗi:

   Cạm bẫy: Chỉnh sửa đối tượng error trực tiếp trong khối `catch`, đặc biệt nếu nó sau đó được ném lại hoặc truyền cho một trình xử lý khác. Điều này có thể dẫn đến các tác dụng phụ không mong muốn hoặc mất ngữ cảnh lỗi ban đầu.

   Cách tránh: Nếu bạn cần làm phong phú thêm một lỗi, hãy tạo một đối tượng lỗi mới bao bọc đối tượng ban đầu, hoặc truyền ngữ cảnh bổ sung một cách riêng biệt. Lỗi ban đầu nên được giữ nguyên để mục đích gỡ lỗi.

Bằng cách cố tình tránh những cạm bẫy phổ biến này, việc xử lý lỗi TypeScript của bạn sẽ trở nên mạnh mẽ hơn, minh bạch hơn và cuối cùng đóng góp vào một ứng dụng ổn định và thân thiện với người dùng hơn.

Kết luận

Xử lý lỗi hiệu quả là nền tảng của phát triển phần mềm chuyên nghiệp và TypeScript nâng cao kỷ luật quan trọng này lên một tầm cao mới. Bằng cách áp dụng các mẫu xử lý lỗi đảm bảo kiểu, các nhà phát triển có thể vượt ra ngoài việc khắc phục sự cố theo phản ứng để thiết kế hệ thống chủ động, xây dựng các ứng dụng vốn đã mạnh mẽ, có thể dự đoán và dễ bảo trì hơn.

Chúng ta đã khám phá một số mẫu mạnh mẽ:

• Kiểm tra Kiểu khi Chạy: Thu hẹp một cách an toàn các lỗi unknown trong các khối catch bằng cách sử dụng instanceof Error và các trình bảo vệ kiểu tùy chỉnh để đảm bảo truy cập có thể dự đoán vào các thuộc tính lỗi.
• Các Lớp Lỗi Tùy chỉnh: Thiết kế một hệ thống phân cấp các loại lỗi có ý nghĩa ngữ nghĩa kế thừa lớp Error cơ sở, cung cấp thông tin ngữ cảnh phong phú và tạo điều kiện xử lý chính xác bằng các kiểm tra instanceof.
• Mẫu Monad Kết quả/Either: Một phương pháp chức năng thay thế mã hóa rõ ràng thành công và thất bại trong kiểu trả về của hàm, buộc người gọi phải xử lý cả hai kết quả và giảm sự phụ thuộc vào các cơ chế ngoại lệ truyền thống.
• Xử lý Lỗi Tập trung: Triển khai các trình xử lý lỗi toàn cục (ví dụ: middleware, error boundaries) để đảm bảo ghi nhật ký, giám sát và phản hồi người dùng nhất quán trên toàn bộ ứng dụng, phân biệt giữa lỗi vận hành và lỗi lập trình.

Mỗi mẫu cung cấp những lợi thế riêng, và lựa chọn tối ưu thường phụ thuộc vào ngữ cảnh cụ thể, phong cách kiến trúc và sở thích của nhóm. Tuy nhiên, điểm chung của tất cả các phương pháp này là cam kết về an toàn kiểu. Hệ thống kiểu nghiêm ngặt của TypeScript đóng vai trò như một người bảo vệ mạnh mẽ, hướng dẫn bạn hướng tới các hợp đồng lỗi mạnh mẽ hơn và giúp bạn phát hiện các sự cố tiềm ẩn ở thời điểm biên dịch thay vì thời gian chạy.

Việc áp dụng các chiến lược này là một khoản đầu tư mang lại lợi nhuận về sự ổn định của ứng dụng, năng suất của nhà phát triển và sự hài lòng chung của người dùng, đặc biệt là khi hoạt động trong bối cảnh phần mềm toàn cầu năng động và đa dạng. Hãy bắt đầu tích hợp các mẫu xử lý lỗi an toàn kiểu này vào các dự án TypeScript của bạn ngay hôm nay và xây dựng các ứng dụng đứng vững trước những thách thức không thể tránh khỏi của thế giới kỹ thuật số.