The snippet below (in java) gives an example of my question.
try {
// code implementation here
}
} catch (Exception ex) {
}
Now, is that a good practice? Does it affect code performance. Is it always better to be specific with the exception you want to catch or just always all exception and do not bother doing something like this?
try {
//code implementation
} catch (IOException | SQLException | NullPointerException ex ) {
}
1
It is only good practice to catch a specific exception if it can actually be handled by the catch block.
Very often, programmers assume that the fault can be handled at all, close to the point of occurrence. This is often wrong. To understand why, we need to explore what “handling” means.
Your second snippet:
try {
// code implementation
} catch (IOException | SQLException | NullPointerException ex ) {
// handle exception
}
implies that there could be some useful action which could handle the caught exception. But this is often not so. As was noted in the comments, performance is irrelevant if the code gives incorrect results.
About the only thing you can do with a NullPointerException is to log everything salient for debugging and die; any further attempt to continue has a high probability of stomping on the heap and breaking other things down-stream. This exception results from a software defect and cannot be properly handled at all.
I’ll assume the code implementation consists of reading a istream. Handling an IOException could be as simple as re-reading the part that threw the exception (if caused by an interrupted system call) but that’s the rare case and an over-generalized exception. If the error is FileNotFoundException, you’ve got an upstream defect which cannot be handled in this context. Who could handle it? The code which created the istream could have handled the exception if there was a reasonable alternative file to open, but the sample snippet should lack the information. If we were trying to open a file with no reasonable alternate, all the opener can do is throw an exception itself.
Why? Because there is a contract between the opening code and its caller that says “you give me a pathname, and I will open it for you and give you an istream”. Upon FileNotFoundException, the opening code has failed to fulfill its contract and will induce failures in the caller and other places where the istream is accessed. It is this violation of contract is the strongest case for exceptions.
Let’s assume that the FileNotFoundException was thrown in a long running program like an editor. It would be rude for the application to crash just because you typo’ed a filename. In this case, the exception should be allowed to propagate up to the main loop which actually can handle it: namely by informing the user “file not found” thus giving the user an opportunity to try another filename.
When an Exception implies a contract failure that exception must propagate upwards until there is code that can actually rectify the contract failure. If there is no place that failure can be rectified (as in cat not_a_file) the best you can do is print a meaningful error message and (as in cat not_a_file a_file) skip not_a_file.
1
I would assume that checking for specific exceptions would have an impact in performance (even if it is minimal) because the program would compare the exception triggered with 3 different values, instead jumping straight to the exception clause. This would increase the number of CPU cycles taken, hence reduce performance.
Listing all exceptions does not improve readability or functionality of the code though, so I would suggest you catch all exceptions by default, unless you need to catch an exact type of an exception.
2