Best Practices for Handling Java Exceptions: Common Mistakes and Correct Approaches

This article mainly covers several error demonstrations and correct demonstrations for handling Java exceptions. Handling exceptions in Java is not easy, but for testing, simple exception constraints before development can solve most problems.

The article demonstrates the most important scenarios for handling Java exceptions, useful for beginners or for improving exception handling. Exceptions are abnormal situations that occur during program execution.

Never Destroy an Exception in a catch Block

Incorrect example:

catch (NoSuchMethodException e) {
    return null;
}

Never directly return null instead of handling the exception, because it clears the exception information and makes it difficult to discover the cause of the failure.

Declare Specific Checked Exceptions That May Be Thrown

Incorrect example:

public void test() throws Exception {
}

Avoid using the above code; you must declare the specific checked exceptions that a method may throw. If a method can throw many checked exceptions, they should be wrapped in a custom exception with additional information.

Correct example:

public void test() throws SpecificException1, SpecificException2 {
    // implementation
}

Do Not Catch Generic Exception; Catch Specific Subclasses Instead

Incorrect example:

try {
    someMethod();
} catch (Exception e) {
    LOGGER.error("Failed!", e);
}

Catching Exception prevents developers from handling newly introduced checked exceptions, making the code brittle and harder to maintain.

Never Catch Any Throwable Class

Java provides a hierarchy of exception classes under the java.lang package. Throwable is the superclass of all exception types.

The diagram below shows the inheritance relationship of Java exception classes, illustrating why catching Throwable is a bad practice.

└────Throwable
     ├────Error
     │    ├────NoClassDefFoundError
     │    └────OutOfMemoryError
     └────Exception
          ├────RuntimeException
          │    ├────IllegalArgumentException
          │    └────NullPointerException
          ├────FileNotFoundException
          └────IOException

Custom Exceptions Should Preserve Stack Trace

Incorrect example:

catch (NoSuchMethodException e) {
    throw new MyServiceException("Custom error: " + e.getMessage());
}

This approach may lose the original stack trace, making debugging harder.

Correct example:

catch (NoSuchMethodException e) {
    throw new MyServiceException("Custom error: ", e);
}

Do Not Log and Throw the Same Exception

Incorrect example:

catch (NoSuchMethodException e) {
    LOGGER.error("Error:", e);
    throw e;
}

Logging and then re‑throwing the exception creates duplicate log entries, cluttering logs and making bug tracing harder.

Never Throw an Exception from a finally Block

Incorrect example:

try {
    someMethod(); // may throw
} finally {
    cleanUp(); // if this also throws, the original exception is lost
}

If cleanUp() throws an exception while another exception is already pending, the original cause disappears.

Useless catch

catch (NoSuchMethodException e) {
    throw e; // re‑throwing without handling is pointless
}

If you cannot handle the exception in the catch block, the best advice is to let it propagate.

Do Not Handle Exceptions; Use finally Instead of catch

Correct example:

try {
    someMethod();
} finally {
    cleanUp();
}

This is a good habit when you want to ensure cleanup code runs regardless of whether an exception occurs.

Conclusion

Java exception handling is essential and has many solutions for different scenarios. This article helps Java testing beginners gain a basic understanding of how to handle Java exceptions effectively.