Exception Handling Best Practices

Exceptions are only as good as the way you use them. Handled well, they make failures obvious, local and easy to fix. Handled badly, they hide bugs, lose the real cause, and turn a two-minute fix into a day of searching. This lesson collects the habits experienced Java developers follow, each with the reason behind it, and ends with a small before-and-after.

The Habits

Before and After

public class Before {
    static int parse(String s) {
        try {
            return Integer.parseInt(s);
        } catch (Exception e) {
            return 0;                      // swallowed, and hides real bugs
        }
    }
}

public class After {
    static int parseQuantity(String text) {
        if (text == null || text.isBlank()) {
            throw new IllegalArgumentException("Quantity is required");
        }
        try {
            return Integer.parseInt(text.strip());
        } catch (NumberFormatException e) {
            throw new IllegalArgumentException(
                "Quantity must be a whole number, got \"" + text + "\"", e);
        }
    }
 
    public static void main(String[] args) {
        for (String in : new String[] {" 3 ", "three", ""}) {
            try {
                System.out.println("Advitha ordered " + parseQuantity(in));
            } catch (IllegalArgumentException e) {
                System.out.println("Rejected: " + e.getMessage());
            }
        }
    }
}

Advitha ordered 3
Rejected: Quantity must be a whole number, got "three"
Rejected: Quantity is required

What changed

1. Fail fast: blank input is rejected at the start with its own message.
2. Specific catch: only NumberFormatException is caught, so unrelated bugs still surface.
3. No swallowing: instead of a silent 0, the caller gets a clear exception it can show to the user.
4. Cause kept: the original NumberFormatException is attached.
5. Useful message: it says what was expected and what arrived.

Exceptions Cost Time

Creating an exception records the whole call stack, which is relatively slow. In one run of 200,000 throws, creating normal exceptions took about 70 ms, while the same loop with a plain if check took under 1 ms. That's nothing for real errors, but it's a reason not to use exceptions as ordinary control flow, such as ending a loop.

Common Mistakes

e.printStackTrace() left in production code. Use a logger, which records time, thread and context.

throws Exception everywhere. Declare the specific checked exceptions.

Catching and returning null. The caller then fails later with a NullPointerException far from the real cause.

Interview Corner

Practice

1. Easy: Find the problems in this code and rewrite it: try { save(order); } catch (Exception e) { }.
2. Harder: Rewrite a method that returns -1 for "not found" so that it either returns an Optional or throws a custom exception, and explain which you'd choose and why.

Key Takeaways