Checked vs Unchecked — cuộc tranh luận lớn trong thiết kế Java

TL;DR: Java là ngôn ngữ phổ biến duy nhất phân chia ngoại lệ thành hai nhóm: Checked (buộc phải khai báo throws hoặc bắt qua try-catch) và Unchecked (lớp con của RuntimeException, tự do truyền dẫn). Dù mục tiêu ban đầu là nâng cao độ tin cậy, Checked Exception lại tạo ra gánh nặng lớn về boilerplate, phá vỡ tính tương thích với Stream/Lambda, và thúc đẩy thói quen nuốt ngoại lệ. Hệ sinh thái Java hiện đại (Spring, Hibernate, Jackson) hầu hết đã chuyển dịch sang Unchecked Exception làm mặc định.

Khi Java ra đời vào năm 1995, James Gosling và nhóm thiết kế đặt nhiều kỳ vọng vào Checked Exception: họ muốn các phương thức phải ký kết hợp đồng rõ ràng về mọi rủi ro có thể phát sinh. Tuy nhiên, sau gần 30 năm phát triển, không một ngôn ngữ hiện đại nào sau đó (như C#, Kotlin, Go, Rust, TypeScript, Swift) học tập mô hình Checked Exception của Java.

1. Định nghĩa kỹ thuật: Khác biệt ở tầng biên dịch javac

Bảng phân loại cốt lõi:

Điểm mấu chốt: Khác biệt này chỉ tồn tại lúc biên dịch.

Trong cấu trúc file .class, máy ảo JVM không có bất kỳ cờ hiệu nào phân biệt hai loại này. Mọi ngoại lệ đều được kích hoạt bằng cùng một chỉ lệnh athrow và phân giải qua Exception Table.

2. Cách Checked Exception ép buộc lập trình viên

Khi một phương thức gọi hàm có khai báo checked exception (ví dụ đọc file danh mục thư viện):

public String readCatalogJson(String path) {
    FileReader reader = new FileReader(path); // COMPILE ERROR: Unhandled exception type FileNotFoundException
    BufferedReader br = new BufferedReader(reader);
    return br.readLine();                     // COMPILE ERROR: Unhandled exception type IOException
}

Trình biên dịch buộc bạn phải chọn một trong hai con đường:

Lựa chọn 1: Đẩy trách nhiệm lên tầng trên bằng từ khoá throws

public String readCatalogJson(String path) throws IOException {
    FileReader reader = new FileReader(path);
    BufferedReader br = new BufferedReader(reader);
    return br.readLine();
}

Nhược điểm: Bất kỳ ai gọi readCatalogJson (kể cả tầng Service hoặc Controller) đều bị lây nhiễm (signature pollution) và buộc phải tiếp tục khai báo throws IOException.

Lựa chọn 2: Xử lý tại chỗ bằng khối try-catch

public String readCatalogJson(String path) {
    try (BufferedReader br = new BufferedReader(new FileReader(path))) {
        return br.readLine();
    } catch (IOException e) {
        logger.error("Doc tap tin that bai: " + path, e);
        return null;
    }
}

3. Vì sao Checked Exception bị chỉ trích trong thực tế?

3.1 Ô nhiễm chữ ký hàm (Signature Pollution)

Hãy hình dung hệ thống quản lý mượn trả: Tầng Repository dùng JDBC nên ném SQLException. Tầng Service gọi Repository nên phải khai throws SQLException. Tầng Controller gọi Service cũng phải khai throws SQLException. Nếu sau này hệ thống chuyển từ PostgreSQL sang MongoDB (ném MongoException), bạn phải thay đổi chữ ký phương thức trên toàn bộ các tầng kiến trúc. Điều này phá vỡ hoàn toàn tính đóng gói (Encapsulation).

3.2 Xung đột với Stream API và Functional Programming

Kể từ Java 8, Functional Interfaces như Function<T, R> hay Consumer<T> không khai báo bất kỳ checked exception nào trong định nghĩa:

List<String> filePaths = List.of("books.json", "members.json");

// LOI BIEN DICH: Unhandled exception: java.io.IOException
List<String> contents = filePaths.stream()
    .map(path -> readCatalogJson(path))
    .toList();

Biểu thức Lambda không thể ném checked exception nếu interface mục tiêu không cho phép. Điều này buộc lập trình viên phải chèn những khối try-catch vụng về vào ngay bên trong thân lambda.

Giải pháp chuẩn: Kỹ thuật uncheck Function Wrapper

Để giữ Stream API trong sáng, chúng ta xây dựng một Utility Helper:

@FunctionalInterface
public interface ThrowingFunction<T, R, E extends Exception> {
    R apply(T t) throws E;

    static <T, R> Function<T, R> uncheck(ThrowingFunction<T, R, ?> function) {
        return arg -> {
            try {
                return function.apply(arg);
            } catch (Exception e) {
                throw new RuntimeException(e);
            }
        };
    }
}

// Su dung cuc ky gon gang trong Stream:
List<String> contents = filePaths.stream()
    .map(ThrowingFunction.uncheck(this::readCatalogJson))
    .toList();

3.3 Khuyến khích thói quen xấu: Nuốt ngoại lệ

Khi bị compiler ép phải catch những ngoại lệ mà tại vị trí đó lập trình viên không biết phải làm gì để khôi phục (ví dụ InterruptedException khi đang chạy một tác vụ nền nhỏ), nhiều người có xu hướng viết khối catch rỗng. Kết quả là Checked Exception vô tình làm giảm độ an toàn của hệ thống thay vì tăng lên.

4. Nguyên tắc thiết kế từ Effective Java (Joshua Bloch)

Joshua Bloch đưa ra hai lời khuyên quan trọng trong Effective Java:

• Item 70: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors (Dùng checked exception cho các tình huống có thể khôi phục được và dùng unchecked exception cho lỗi lập trình).
• Item 71: Avoid unnecessary use of checked exceptions (Tránh lạm dụng checked exception).

Khi nào thực sự nên dùng Checked Exception?

Chỉ dùng khi thoả mãn đồng thời hai câu hỏi sau:

1. Người gọi có thể làm gì để khôi phục không? (Ví dụ: Thẻ ngân hàng không đủ số dư -> người dùng có thể nạp thêm tiền hoặc chọn thẻ khác).
2. Hành động khôi phục đó có thực tế không? Nếu câu trả lời duy nhất của tầng gọi là "ghi log và báo lỗi 500", đó chắc chắn phải là Unchecked Exception.

5. Quy tắc chuyển đổi: Exception Translation Pattern

Cách tiếp cận chuẩn mực của các framework hiện đại (như cách Spring Data chuyển đổi SQLException thành DataAccessException):

• Bắt Checked Exception ở tầng giao tiếp hạ tầng ngoài cùng (I/O, Network, JDBC).
• Bọc nó thành một Unchecked Domain Exception tương ứng và truyền ngoại lệ gốc vào cause.

public class LibraryCatalogRepository {
    public void save(LibraryItem item) {
        try {
            databaseClient.insert(item);
        } catch (SQLException e) {
            // Chuyen doi checked SQLException thanh unchecked RepositoryException
            throw new LibraryStorageException("Loi luu tru an pham ID: " + item.getId(), e);
        }
    }
}

Caller ở tầng Service và Controller không còn bị ô nhiễm chữ ký hàm, nhưng toàn bộ vết tích kỹ thuật của SQLException vẫn được bảo toàn nguyên vẹn trong Call Stack log.

6. Deep Dive Oracle & Tài liệu tham khảo

7. Tự kiểm tra kiến thức

Bài tiếp theo: try-with-resources — quản lý vòng đời tài nguyên tự động