Why I Avoid Checked Exceptions

Checked exceptions are one of Java’s more controversial design decisions, and after 20 years of building production systems, I’ve come down firmly on one side: I avoid them wherever I can. Early in my career at Co-op, I inherited a codebase riddled with throws IOException chains and try-catch blocks that were catching exceptions just to rethrow them or — worse — swallow them silently. It was noise that obscured the actual error-handling logic. Here’s why I prefer unchecked exceptions, with practical examples of how to handle errors more cleanly.

The Problem with Checked Exceptions

Checked exceptions (like IOException) force you to catch or declare them, which sounds great but backfires. In Co-op’s pricing system, I dealt with FileNotFoundException for reading price files, and it was a mess:

Boilerplate Overload: Every method touching a file needed try-catch or throws, cluttering my code.
Client Burden: Callers had to handle exceptions they didn’t care about, frustrating my team in ESG’s engine.
Maintenance Pain: Adding a new checked exception broke method signatures, forcing cascading changes in Mosaic’s pipeline.

ProTip: If your code feels like a try-catch jungle, checked exceptions might be the culprit.

A Real-World Example

In Co-op’s pricing system, I read price data from a file using checked exceptions:

public String readPriceData(String filePath) throws FileNotFoundException {
    Scanner scanner = new Scanner(new File(filePath));
    return scanner.nextLine();
}

Every caller needed:

try {
    String data = readPriceData("prices.txt");
} catch (FileNotFoundException e) {
    // Handle or rethrow
}

This bloated my Spring Boot controllers and annoyed teammates who just wanted the data. I switched to unchecked exceptions for cleaner code.

Why Unchecked Exceptions Are Better

Unchecked exceptions (like RuntimeException) don’t force handling, giving you flexibility. In Ribby Hall’s sync, I wrapped checked exceptions in a custom unchecked one:

public class DataAccessException extends RuntimeException {
    public DataAccessException(Throwable cause) {
        super(cause);
    }
}

public String readPriceData(String filePath) {
    try {
        Scanner scanner = new Scanner(new File(filePath));
        return scanner.nextLine();
    } catch (FileNotFoundException e) {
        throw new DataAccessException(e);
    }
}

Now, callers can handle it only if needed:

String data = readPriceData("prices.txt"); // No try-catch required

In Mosaic’s pipeline, I used Spring’s ResponseStatusException for API errors, keeping controllers clean:

throw new ResponseStatusException(HttpStatus.NOT_FOUND, "Price file missing");

When to Use Checked Exceptions

Checked exceptions make sense for critical, recoverable errors where the caller must act, like database rollbacks in ESG’s engine. But they’re overused. I stick to unchecked exceptions 90% of the time for simplicity and maintainability.

Best Practices for Exception Handling

Here’s what I’ve learned:

Wrap Checked Exceptions: Convert checked exceptions to unchecked ones (e.g., DataAccessException) to reduce boilerplate.
Use Descriptive Exceptions: In Co-op’s system, custom exceptions clarified error causes.
Centralize Handling: In Spring Boot apps, I use @ControllerAdvice to handle exceptions globally, keeping Mosaic’s APIs clean.
Avoid Swallowing Exceptions: Logging and ignoring errors in Ribby Hall’s sync hid bugs—always propagate or handle meaningfully.

ProTip: Centralize exception handling in Spring Boot with @ControllerAdvice to keep your controllers lean.

Conclusion

Checked exceptions have burned me too many times. In Co-op’s pricing system, they bloated my code; in Mosaic’s pipeline, they complicated maintenance. Unchecked exceptions, like custom RuntimeException subclasses, keep my code clean and flexible. Next time you’re tempted to throws IOException, consider wrapping it in an unchecked exception. Check Oracle’s Java docs or my clean code tips here for more.

Got an exception handling trick? Share it with me here, I’d love to swap stories!

Java Exceptions Clean Code