It is a bad idea to have an application with exception handling like this:
catch(SQLException sqlexception) { //This is not supposed happen }
This is not supposed happen?!!
Seriously?
We all know that exceptions are not supposed to happen. Still we catch them so that if they do happen, we can take some steps to prevent additional damage.
It is good to handle exceptions and give meaningful messages to the user. At the same time, avoid using phrases like “An error has occurred” in messages. Tell what error occurred exactly, and suggest some steps to solve the issue. Try sending the stack trace to some log file so that somebody can clearly understand where and why the error occurred.
Exception handling is not the art of concealing every single error from the user and pretending like no error occurred.
This is why checked exceptions are such a bad idea. Instead of having exceptions propagate and get noticed, Java emphasizes hiding them to ease development. Exceptions breaking your app is better then exceptions going unhandled because you just need to get the code out.
There seems to be a culture, where error handling is thought to be extraneous, that drives this sort of practice. What most developers need to understand is that error handling is ALWAYS going to be part of any program, and a large part at that (40-50% i’d say).
Generally I’m a bit mixed about checked exceptions but i still believe it goes back to the culture issue. Java enforces the handling, but it’s still up to the developer to do something meaningful with those catch blocks.
The problem isn’t with exceptions, it’s with “this can’t happen so who cares” type thinking. It shows up in if-else-if constructs and switches as well.
switch ( foo ) {
case BAR: handleBar(); break;
case BAZ: handleBaz(); break;
…
default: /* can’t happen */
}
There are times when one doesn’t *care* if some code throws an exception, but this is normally a tiny, tiny fraction of the time. The advice to print the stack trace to a log file (or even stderr) is an excellent policy.
The rest of the time, we presumably care, but either don’t know what to do about an exception, or our API doesn’t allow for checked exceptions. Wrapping that checked exception is better than ignoring it:
try {
someObject.mightThrowCheckedException();
} catch (SomeCheckedException scx) {
throw new RuntimeException( scx);
}
And if it truly is a “Can’t Happen”, why, an error is called for:
try {
someObject.saysItThrowsCheckedExceptionButItLies();
} catch (LyingCheckedException lcx) {
InternalError ie = new InternalError(
“Programmer Assumption Violation” );
ie.initCause( lcx );
throw ie;
}
Or better yet:
public class PAVError extends InternalError {
public PAVError( Throwable t ) {
super(“Programmer Assumption Violation”);
initCause( t );
}
…
}
It would be nice if the difference between a checked and an unchecked exception were in how the exception is thrown, rather than the ancestor of the exception.
my team lead always catches and ignores exceptions … no matter what … he does it like
Try
{
…
…
}
Catch (Exception ex)
{
//empty
}
the reason he gives is, that it shows exception when he’s debugging what ignores in runtime. this is lamest of all excuses to ignore exceptions i have ever heard.
Yep. Checked Exceptions are a joke, invented in a short sighted world where there wouldnt be huge layered apps.
In your app API ALWAYS wrap checked exceptions as RuntimeExceptions, and make sure that the “top level exception” handler logs and can return the original exception in its, getCause() method.
Swallowing exceptions is definitely a chicken shit response to not knowing how to throw them up higher, and deal with them at the user level.
– Well said. A well defined exception handling mechanism is a must for any software application.