Java - Top 5 Exception Handling Coding Practices to Avoid

Following are some of the reasons why one should avoid invoking printStackTrace method on Throwable/Exception classes and instead use Logger method using one of the frameworks such as LogBack or Log4J:

• Difficult to Retrieve Logs for Debugging:The logs written using printStackTrace is written to System.err which is hard to route or filter elsewhere. Instead, using Loggers, it is easy to retrieve logs for debugging purpose.
• Violation of Coding Best Practices:Generally, as per coding guidelines in production-ready applications, developers need to use Logger methods for logging different level of information. However, when it comes to exception handling, the instances of printStackTrace are commonly found in various places. This is, thus, a violation of coding practice and, thus, should be avoided.
• Following are some good pages explaining the reasons in detail:
  • Why is exception.printStackTrace() considered bad practice?
  • Avoid printStackTrace(); use a logger call instead

Generic exceptions such as Error, RuntimeException, Throwable and Exception should never be thrown

Following are some of the reasons why Generic Exceptions/Throwable should never be thrown:

• The primary reason why one should avoid throwing Generic Exceptions, Throwable, Error etc is that doing in this way prevents classes from catching the intended exceptions. Thus, a caller cannot examine the exception to determine why it was thrown and consequently cannot attempt recovery.
• Additionally, catching RuntimeException is considered as a bad practice. And, thus, throwing Generic Exceptions/Throwable would lead the developer to catch the exception at a later stage which would eventually lead to further code smells.

Following is the code sample that represents this code smell:

public void foo(String bar) throws Throwable { // Non-compliant
  throw new RuntimeException("My Message");    // Non-Compliant
}
// One other instance which displays throwing Exception
public void doSomething() throws Exception {...} // Non-compliant code

Instead, one would want to do something like following:

public void foo(String bar) { 
  throw new CustomRuntimeException("My Message");    // Compliant
}

Exception handlers should preserve the original exception

When writing code for doing exception handling, I have often seen code such as following which does some of the following:

• In the code sample below, the exception is lost.
  
  

  try { 
  /* ... */ 
  } catch( Exception e ) {
  SomeLogger.info( e.getMessage() ); // The exception is lost. Just that exception message is written; Also, context information is not logged.
  }

  
  
  
• In the code sample below, whole exception object is lost.
  
  

  try { 
  /* ... */ 
  } catch( Exception e ) {
  SomeLogger.info( "some context message" ); // The exception is lost
  }

• In the code sample below, no context message is provided.
  
  

  try { 
  /* ... */ 
  } catch( Exception e ) {
          SomeLogger.info( e ); // No context message
  }