Checked vs Unchecked Exceptions

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

// 1. DECLARING CHECKED EXCEPTIONS
// When a method can throw a checked exception, it MUST declare this in its signature
public class FileProcessor {
    
    // The 'throws' clause is part of the method's contract
    // Any caller of this method must handle or propagate the exception
    public String readFile(String path) throws IOException {
        FileReader reader = new FileReader(path);  // Can throw FileNotFoundException
        BufferedReader buffered = new BufferedReader(reader);
        
        StringBuilder content = new StringBuilder();
        String line;
        while ((line = buffered.readLine()) != null) {  // Can throw IOException
            content.append(line).append("
");
        }
        
        buffered.close();  // Can throw IOException
        return content.toString();
    }
    
    // Multiple checked exceptions must all be declared
    public void processConfigFile(String path) 
            throws IOException, ParseException, ConfigurationException {
        String content = readFile(path);
        Config config = parseConfig(content);  // throws ParseException
        validateConfig(config);                 // throws ConfigurationException
    }
}
 
// 2. HANDLING CHECKED EXCEPTIONS
// Callers must either catch the exception or propagate it
public class Application {
    
    // Option A: Catch and handle the exception
    public void loadConfiguration() {
        FileProcessor processor = new FileProcessor();
        try {
            String content = processor.readFile("config.json");
            System.out.println("Config loaded: " + content);
        } catch (IOException e) {
            // Handle the exception - this is MANDATORY
            System.err.println("Failed to load config: " + e.getMessage());
            loadDefaultConfiguration();
        }
    }
    
    // Option B: Propagate the exception to caller
    // This method now also declares 'throws IOException'
    public String loadUserData() throws IOException {
        FileProcessor processor = new FileProcessor();
        return processor.readFile("user_data.json");  // Propagated to caller
    }
    
    // Option C: Catch and wrap in a different exception
    public void initializeSystem() throws SystemInitializationException {
        FileProcessor processor = new FileProcessor();
        try {
            processor.processConfigFile("system.conf");
        } catch (IOException | ParseException | ConfigurationException e) {
            // Wrap in a higher-level exception
            throw new SystemInitializationException(
                "Failed to initialize system configuration", e);
        }
    }
}
 
// 3. THE COMPILER ENFORCEMENT
// This code will NOT compile - IOException is not handled or declared
public class InvalidCode {
    public void brokenMethod() {
        FileProcessor processor = new FileProcessor();
        // COMPILER ERROR: Unhandled exception type IOException
        // String content = processor.readFile("file.txt");
    }
}

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

// Example: Checked exceptions enabling robust recovery
 
public class TransactionService {
    
    private final PaymentGateway paymentGateway;
    private final InventoryService inventoryService;
    private final NotificationService notificationService;
    
    /**
     * Process an order with comprehensive error handling.
     * 
     * The checked exceptions FORCE us to handle each failure mode explicitly.
     * Without checked exceptions, we might forget to handle PaymentException,
     * leaving customers charged for undelivered orders.
     */
    public OrderResult processOrder(Order order) {
        try {
            // Step 1: Reserve inventory
            inventoryService.reserve(order.getItems());
            
            try {
                // Step 2: Charge customer
                PaymentReceipt receipt = paymentGateway.charge(
                    order.getCustomer(), 
                    order.getTotal()
                );
                
                try {
                    // Step 3: Confirm inventory reservation
                    inventoryService.confirmReservation(order.getItems());
                    
                    // Step 4: Send confirmation (failure here is non-fatal)
                    try {
                        notificationService.sendConfirmation(order, receipt);
                    } catch (NotificationException e) {
                        // Log but don't fail the order
                        logger.warn("Failed to send confirmation", e);
                    }
                    
                    return OrderResult.success(receipt);
                    
                } catch (InventoryException e) {
                    // Inventory confirmation failed - refund the customer
                    paymentGateway.refund(receipt);
                    throw new OrderProcessingException(
                        "Inventory confirmation failed after payment", e);
                }
                
            } catch (PaymentException e) {
                // Payment failed - release the inventory reservation
                inventoryService.releaseReservation(order.getItems());
                return OrderResult.paymentFailed(e.getMessage());
            }
            
        } catch (InventoryException e) {
            // Initial reservation failed - nothing to clean up
            return OrderResult.outOfStock(e.getUnavailableItems());
        }
    }
}
 
// The throws clauses on these methods FORCE the above handling:
interface PaymentGateway {
    PaymentReceipt charge(Customer c, Money amount) throws PaymentException;
    void refund(PaymentReceipt receipt) throws PaymentException;
}
 
interface InventoryService {
    void reserve(List<Item> items) throws InventoryException;
    void confirmReservation(List<Item> items) throws InventoryException;
    void releaseReservation(List<Item> items);  // Best effort, no exception
}

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

// Problem 1: The Swallowed Exception Anti-Pattern
// When checked exceptions become burdensome, developers take shortcuts
 
public class LazyDeveloper {
    public void processData() {
        try {
            riskyOperation();
        } catch (IOException e) {
            // "I'll deal with this later" - Famous last words
            // This is WORSE than not having checked exceptions at all
            // because now the failure is completely silent
        }
        
        // Alternative bad pattern: wrapping in RuntimeException
        try {
            anotherRiskyOperation();
        } catch (SQLException e) {
            // Defeats the purpose of checked exceptions
            throw new RuntimeException(e);
        }
    }
}
 
// Problem 2: Signature Pollution
// Low-level changes ripple through the entire codebase
 
// Before: Simple signature
interface UserRepository {
    User findById(String id);
}
 
// After adding caching with potential IOException
// Now EVERY caller up the chain must handle IOException
interface UserRepository {
    User findById(String id) throws CacheException, IOException;
}
 
// This forces changes in:
class UserService {
    User getUser(String id) throws CacheException, IOException { ... }
}
 
class UserController {
    Response handleRequest(String id) throws CacheException, IOException { ... }
}
 
// And so on, all the way up the call stack...
 
// Problem 3: Lambda Incompatibility
// Standard functional interfaces don't work with checked exceptions
 
public class StreamProcessor {
    public void processFiles(List<String> paths) {
        // This WON'T COMPILE - Function interface doesn't declare IOException
        // paths.stream()
        //     .map(path -> readFile(path))  // readFile throws IOException
        //     .forEach(System.out::println);
        
        // Ugly workaround 1: Try-catch inside lambda
        paths.stream()
            .map(path -> {
                try {
                    return readFile(path);
                } catch (IOException e) {
                    throw new RuntimeException(e);  // Defeats checked exceptions
                }
            })
            .forEach(System.out::println);
    }
    
    // Ugly workaround 2: Custom functional interface
    @FunctionalInterface
    interface IOFunction<T, R> {
        R apply(T t) throws IOException;
    }
    
    // But now standard library methods don't accept this interface
    private String readFile(String path) throws IOException {
        return Files.readString(Path.of(path));
    }
}
 
// Problem 4: Abstraction Leakage
// Implementation details leak through exception types
 
// Low-level: Uses MySQL
class MySQLUserDAO {
    User findById(String id) throws SQLException { ... }
}
 
// Mid-level: Should abstract away database details
// But now the service knows about SQLException - a MySQL detail!
class UserService {
    User getUser(String id) throws SQLException { ... }
}
 
// High-level: Now the controller knows about SQL too!
class UserController {
    Response getUser(String id) throws SQLException { ... }
}
 
// If we switch to MongoDB, we need to change exception types everywhere
// The abstraction has leaked, defeating the purpose of layered architecture

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

// Version 1.0 of your library
public interface PaymentProcessor {
    PaymentResult process(Payment payment) throws PaymentDeclinedException;
}
 
// Client code written against v1.0
public class ClientApplication {
    public void checkout(Cart cart) {
        try {
            processor.process(cart.toPayment());
        } catch (PaymentDeclinedException e) {
            showDeclinedMessage();
        }
        // All checked exceptions are handled - code compiles!
    }
}
 
// Version 2.0: You discover payments can also fail due to network issues
// You want to add NetworkException to help users handle this case
public interface PaymentProcessor {
    PaymentResult process(Payment payment) 
        throws PaymentDeclinedException, NetworkException;  // NEW EXCEPTION
}
 
// PROBLEM: Now all client code fails to compile!
// The ClientApplication.checkout() method no longer handles all exceptions
// Every client must update their code before upgrading to v2.0
 
// This creates a painful choice:
// Option A: Never add new checked exceptions (limits API evolution)
// Option B: Break all clients with every new exception (terrible DX)
// Option C: Wrap everything in a broad exception from the start
public interface PaymentProcessor {
    PaymentResult process(Payment payment) throws PaymentException;
}
// But now we've lost the granularity that made checked exceptions useful!

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

// GOOD USE OF CHECKED EXCEPTION
// The caller can realistically recover, and the failure is expected
 
public class UserInputValidator {
    
    /**
     * Parse and validate user-provided date input.
     * 
     * This is a GOOD use of checked exception because:
     * 1. Invalid input is EXPECTED - users make mistakes
     * 2. The caller CAN recover - show error message, ask again
     * 3. Handling happens at the immediate call site
     */
    public LocalDate parseUserDate(String input) throws InvalidDateFormatException {
        try {
            return LocalDate.parse(input, DateTimeFormatter.ISO_LOCAL_DATE);
        } catch (DateTimeParseException e) {
            throw new InvalidDateFormatException(
                "Please enter date in YYYY-MM-DD format", e);
        }
    }
}
 
// Caller handles immediately - this is natural
public class RegistrationForm {
    public void handleDateInput(String input) {
        try {
            LocalDate birthDate = validator.parseUserDate(input);
            this.birthDate = birthDate;
            moveToNextField();
        } catch (InvalidDateFormatException e) {
            showErrorMessage(e.getMessage());
            highlightField("birthDate");
        }
    }
}
 
// BAD USE OF CHECKED EXCEPTION
// Most callers can't recover, exception propagates through many layers
 
public class DatabaseConnection {
    
    /**
     * This is a POOR use of checked exception because:
     * 1. Database connection failures are usually unrecoverable at the call site
     * 2. The exception will propagate through service, controller, and framework layers
     * 3. Most of those layers will just re-throw or wrap it
     */
    public Connection getConnection() throws DatabaseConnectionException {
        // ...
    }
}
 
// This leads to signature pollution:
class UserRepository {
    User findById(String id) throws DatabaseConnectionException { ... }
}
 
class UserService {
    User getUser(String id) throws DatabaseConnectionException { ... }
}
 
class UserController {
    Response handleRequest(String id) throws DatabaseConnectionException { ... }
}
// None of these intermediate layers can actually DO anything about a database failure!