When handling a caught exception, the original exception's message and stack trace should be logged or passed forward.
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"); }
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 }
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 }