I need to find out best-practice for try-catch when launching a new thread.
Personally, I prefer Option 2.
Which option is the best-practice? Are there any factors that might make either option a best practice in some situations and not others?
Option 1
public void run(){
try{
//do something
}catch(Exception e){
// log
}
}
Option 2
public void run(){
try{
//do something
}catch(Throwable t){
// log
}
}
EDIT: Assume that you are writing the code that has to meet a stringent code review. EDIT 2: I know the difference between the above two options. I am just curious about what is seen as '100% correct' by others.
I would use setDefaultUncaughtExceptionHandler(...) on the thread to catch what the runnable does not handle properly, but when it comes to the runnable itself, it really depends on what it has to achieve and to reasonably anticipate considering a reasonable execution context.
On the other side, creating a separate thread to execute a runnable is not a good strategy IMHO, FutureTask deals with these issues better.
In a root exception handler that simply logs whatever went wrong, distinguishing between Error
and Exception
is pointless, so catching Throwable
is perfectly acceptable.
If instead you were writing some retry logic, I'd catch Exception
, since there really is no point retrying after an Error
- in fact, it could be dangerous, because the error was thrown in code that was not exception safe, and thus might have left the system in an inconsistent state.
Therefore, it depends on what kind of exception handler you are writing.
It is never advisable to catch Throwable
since this includes errors that cannot be handled or avoided such as out of memory error and so on. Thus it is generally much better to catch Exception
and not catch Throwable
. Sometimes it is unavoidable such as when calling invoke method or other reflection methods.
What you are trying to ask about is the concept of a fault barrier and the correct way to implement one should be a standard defined by the project you are working on or the framework you are using.
If your project has a policy to log all exceptions/errors and not let anything print to standard error, you might want to look into using an UncaughtExceptionHandler.
A general best practice would be to catch only instances of RuntimeException.
public void run(){
try{
//do something
}catch(RuntimeException e){
// log
}
}
Catching Exception
is too general because the Java language requires programs to deal with checked exceptions. By catching even checked exceptions at your fault barrier you are allowing the code in the //do something
block to be sloppy and not handle checked exceptions.
Catching Error
or Throwable
is also generally considered a bad practice since an Error typically indicates that the JVM is in a state where it can not continue to function meaningfully.
Here is a good (and somewhat relevant) article on exception handling: http://www.oracle.com/technetwork/articles/entarch/effective-exceptions-092345.html
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With