One should try and avoid catching Throwable and Errors in their code. There is a very detailed article written on this topic on this page. Following is an example of non-compliant code taken from Spring-core code:
try {
cl = Thread.currentThread().getContextClassLoader();
}catch (Throwable ex) { //Non-compliant code
}
In nutshell, following are some of the reasons:
Above said, there are reasons why people still go for catching Throwable. The data errors such as encoding issues etc which are not known at programming time can be caught using this technique. However, catching Throwable such as InternelError or OutofMemoryError would not be of any help and should therefore be thrown. Thus, one should avoid writing code consisting of catching Throwable as general practice.
Following is an example of code that represents the usage of invocation of printStackTrace on Throwable class.
try {
/* ... */} catch(Throwable t) {
t.printStackTrace(); // Non-Compliant
}
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:
Following are some of the reasons why Generic Exceptions/Throwable should never be thrown:
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
}
When writing code for doing exception handling, I have often seen code such as following which does some of the following:
try {
/* ... */
} catch( Exception e ) {
SomeLogger.info( e.getMessage() ); // The exception is lost. Just that exception message is written; Also, context information is not logged.
}
try {
/* ... */
} catch( Exception e ) {
SomeLogger.info( "some context message" ); // The exception is lost
}
try {
/* ... */
} catch( Exception e ) {
SomeLogger.info( e ); // No context message
}
As a best practice, one would want to do something like following:
try {
/* ... */
} catch( Exception e ) {
SomeLogger.info( "some context message", e ); // Context message is there. Also, exception object is present
}
In case of throwable exceptions, following should be done:
try {
/* ... */} catch (Exception e) {
throw new CustomRuntimeException("context", e); // Context message is there. Also, exception object is present
}
The primary reason why one should avoid using System.out or System.err to log exception is the fact that one might simply loose the important error messages. Instead one should use Logging frameworks such as Log4J or LogBack etc to log the exceptions.
Last updated: 3rd May, 2024 Have you ever wondered why some machine learning models perform…
Last updated: 2nd May, 2024 The success of machine learning models often depends on the…
When working on a machine learning project, one of the key challenges faced by data…
Last updated: 1st May, 2024 The bias-variance trade-off is a fundamental concept in machine learning…
Last updated: 1st May, 2024 As a data scientist, understanding the nuances of various cost…
Last updated: 1st May, 2024 In this post, you will learn the concepts related to…