Common Misconceptions in Java Exception Handling and Best Practices

This article focuses on common misconceptions and pitfalls in Java exception selection and usage, aiming to help developers master proper exception handling principles to improve code robustness, user experience, and product value.

Misconception 1: Choosing the Wrong Exception Type

Figure 1 illustrates the exception hierarchy, distinguishing checked and unchecked exceptions. Many developers mistakenly treat unchecked exceptions as universally convenient and consider checked exceptions unnecessary, leading to misuse.

Two typical scenarios:

When the calling code cannot continue and must terminate immediately (e.g., server connection failure, invalid parameters), unchecked exceptions are appropriate because they do not require explicit handling.

When the calling code needs to recover or perform additional processing (e.g., handling SQLException ), defining the exception as checked forces developers to catch it, clean up resources, and optionally rethrow an unchecked exception.

Misconception 2: Displaying Raw Exceptions to Users

Printing full stack traces directly on a web page (as JSP containers do by default) provides no useful information to end‑users and should be avoided.

package com.ibm.dw.sample.exception;
/**
 * Custom RuntimeException with an error code
 */
public class RuntimeException extends java.lang.RuntimeException {
    // Default error code
    public static final Integer GENERIC = 1000000;
    // Specific error code
    private Integer errorCode;
    public RuntimeException(Integer errorCode, Throwable cause) {
        this(errorCode, null, cause);
    }
    public RuntimeException(String message, Throwable cause) {
        // Use generic error code
        this(GENERIC, message, cause);
    }
    public RuntimeException(Integer errorCode, String message, Throwable cause) {
        super(message, cause);
        this.errorCode = errorCode;
    }
    public Integer getErrorCode() {
        return errorCode;
    }
}

By attaching an error code to an exception, developers can map it to user‑friendly messages while still retaining detailed diagnostic information.

Misconception 3: Polluting Layered Architecture with Exceptions

Throwing a checked exception like SQLException from a DAO layer forces upper layers to handle or re‑throw it, tightly coupling them.

public Customer retrieveCustomerById(Long id) throws SQLException {
    // Query database by ID
}

A better approach isolates the DAO exception:

public Customer retrieveCustomerById(Long id) {
    try {
        // Query database by ID
    } catch (SQLException e) {
        // Wrap checked exception in an unchecked one to reduce coupling
        throw new RuntimeException(SQLErrorCode, e);
    } finally {
        // Close connection, clean resources
    }
}

Misconception 4: Ignoring Exceptions

Simply printing the stack trace to the console without halting execution can lead to further errors.

public void retrieveObjectById(Long id) {
    try {
        // ... code that throws SQLException
    } catch (SQLException ex) {
        // Printing stack trace is useless in production
        ex.printStackTrace();
    }
}

Refactor to rethrow a runtime exception after proper logging:

public void retrieveObjectById(Long id) {
    try {
        // ... code that throws SQLException
    } catch (SQLException ex) {
        throw new RuntimeException("Exception in retrieveObjectById", ex);
    } finally {
        // clean up resultset, statement, connection etc.
    }
}

Misconception 5: Placing Exceptions Inside Loops

Wrapping each iteration of a loop with a try‑catch block wastes resources and can obscure the real source of failure.

for (int i = 0; i < 100; i++) {
    try {
        // ...
    } catch (XXXException e) {
        // ...
    }
}

Misconception 6: Catching All Exceptions with the Base Exception Class

Catching the generic Exception loses specific error information.

public void retrieveObjectById(Long id) {
    try {
        // ... code that may throw IOException
        // ... code that may throw SQLException
    } catch (Exception e) {
        // All potential exceptions are swallowed
        throw new RuntimeException("Exception in retrieveObjectById", e);
    }
}

Handle each checked exception separately:

public void retrieveObjectById(Long id) {
    try {
        // ... code that may throw various exceptions
    } catch (IOException e) {
        throw new RuntimeException(ioCode, "Exception in retrieveObjectById", e);
    } catch (SQLException e) {
        throw new RuntimeException(sqlCode, "Exception in retrieveObjectById", e);
    }
}

Misconception 7: Multi‑Level Wrapping of Unchecked Exceptions

Re‑wrapping an already unchecked exception adds unnecessary layers and discards original information.

try {
    // May throw RuntimeException, IOException, etc.
} catch (Exception e) {
    // Converting everything to RuntimeException loses original data
    throw new RuntimeException(/*code*/, /*msg*/, e);
}

Prefer checking the cause type before re‑wrapping or catch specific exception types.

Misconception 8: Logging the Same Exception Multiple Times

When both a lower‑level class and an upper‑level class log the same exception, the log is duplicated, increasing noise and performance cost.

public class A {
    private static Logger logger = LoggerFactory.getLogger(A.class);
    public void process() {
        try {
            B b = new B();
            b.process();
        } catch (XXXException e) {
            logger.error(e);
            throw new RuntimeException(errorCode, "msg", e);
        }
    }
}

public class B {
    private static Logger logger = LoggerFactory.getLogger(B.class);
    public void process() {
        try {
            // ... code that may throw exception
        } catch (XXXException e) {
            logger.error(e);
            throw new RuntimeException(errorCode, "msg", e);
        }
    }
}

Log only at the outermost layer or use AOP to centralise logging.

Misconception 9: Insufficient Exception Information

Exception messages should include contextual data (e.g., method parameters) to aid debugging.

public void retrieveObjectById(Long id) {
    try {
        // ... code that throws SQLException
    } catch (SQLException ex) {
        throw new RuntimeException("Exception in retrieveObjectById with Object Id:" + id, ex);
    }
}

Misconception 10: Not Anticipating Potential Exceptions

Developers often add catch blocks only after bugs appear in production, leading to incomplete error handling. Understanding the behavior of called code and anticipating possible failures leads to more robust designs.

Misconception 11: Mixing Multiple Third‑Party Logging Libraries

Large projects may inadvertently depend on several logging frameworks, causing incompatibilities and increased maintenance cost. Consolidating logging through a unified abstraction or configuring a single implementation at runtime mitigates this risk.

By following the principles above—choosing the right exception type, avoiding exposure of raw stack traces, limiting exception propagation across layers, and centralising logging—developers can write cleaner, more maintainable Java backend code.

Conclusion

The guidelines presented are based on personal experience; they are not absolute rules but practical recommendations that can help improve Java exception handling practices.