When handling a caught exception, the original exception’s message and stack trace should be logged or passed forward.
Noncompliant code example
try {
/* ... */
} catch (Exception e) { // Noncompliant - exception is lost
LOGGER.info("context");
}
try {
/* ... */
} catch (Exception e) { // Noncompliant - exception is lost (only message is preserved)
LOGGER.info(e.getMessage());
}
try {
/* ... */
} catch (Exception e) { // Noncompliant - original exception is lost
throw new RuntimeException("context");
}
Compliant solution
try {
/* ... */
} catch (Exception e) {
LOGGER.info(e); // exception is logged
}
try {
/* ... */
} catch (Exception e) {
throw new RuntimeException(e); // exception stack trace is propagated
}
try {
/* ... */
} catch (RuntimeException e) {
doSomething();
throw e; // original exception passed forward
} catch (Exception e) {
throw new RuntimeException(e); // Conversion into unchecked exception is also allowed
}
Exceptions
InterruptedException, NumberFormatException, DateTimeParseException, ParseException and
MalformedURLException exceptions are arguably used to indicate nonexceptional outcomes. Similarly, handling
NoSuchMethodException is often required when dealing with the Java reflection API.
Because they are part of Java, developers have no choice but to deal with them. This rule does not verify that those particular exceptions are
correctly handled.
int myInteger;
try {
myInteger = Integer.parseInt(myString);
} catch (NumberFormatException e) {
// It is perfectly acceptable to not handle "e" here
myInteger = 0;
}
Furthermore, no issue will be raised if the exception message is logged with additional information, as it shows that the developer added some
context to the error message.
try {
/* ... */
} catch (Exception e) {
String message = "Exception raised while authenticating user: " + e.getMessage();
LOGGER.warn(message); // Compliant - exception message logged with some contextual information
}
