Philip

No RuntimException can happen due to OutOfMemoryError because the latter extends Error:

java.lang.Object <== java.lang.Throwable <== java.lang.Error <== java.lang.VirtualMachineError <== java.lang.OutOfMemoryError.

So when you catch Exception, you run no risk of catching any Error.

While RuntimeException should not normally be caught because it indicates a programming error, Error should not normally be caught because it is a serious problem and most of the time and abnormal condition.

Philip

:)

thanks for your comment. I don’t share your concern about catching Exception. RuntimeExceptions might happen for all kinds of reasons, like NullPointerExceptions which are certainly due to logic errors, but also OutOfMemoryError or even applicative errors that the developer chose to declare as unchecked exceptions.

I think they should be handled uniformly; whenever an exception is thrown, the fact is that we cannot do what the user asked us to do. We log appropriately and present an appropriate error message to the user. Even logic errors are a fact of life; I want the system to handle them as gracefully as possible.

Exceptions should be exceptional; for instance in my example above, there should probably be a check that the string actually contains a parseable integer, so that no ParseException is ever thrown. Most exceptions should be prevented by checking that an operation can be performed before we perform it. If we do this, then anything that is thrown should either be something that we didn’t think of, like a hole in our validation checks, or something that we cannot possibly do anything about, like our database server is unreachable or we’re out of memory. I don’t think you can gain much by catching exceptions selectively then.

By the way: the pattern that I called the “Fundamental Pattern of Exception Handling” is not something I invented, of course. I learned about it when I worked with the MacApp application framework, circa 1990 :-)

Interesting post, especially the usage of the publish-subscribe pattern to eliminate the tight coupling between tripling the number and sending the email.

I have a question about the following though:

void onTripleButtonPressed() {
try {
tryOnTripleButtonPressed();
} catch (Exception e) {
alertUser(e.getMessage());
}
}

Normally when I see code catching java.lang.Exception, I bring up the following two reasons why I think it should not be done.

The first reason is explained in the Catching Exception antipattern:
https://today.java.net/pub/a/today/2006/04/06/exception-handling-antipatterns.html#catchingException

My other reason why catching java.lang.Exception (or java.lang.Throwable for that matter) is an antipattern is that one of the subclasses of Exception is RuntimeException (http://javajazzle.files.wordpress.com/2011/02/hierarchy_of_java_exceptions.png). So whenever you catch Exception, you are also catching RuntimeException. But runtime exceptions are generally supposed to indicate programming errors.

A correctly working system is generally not expected to encounter runtime exceptions. When a system encounters a runtime exception, you wan to be sure that the system informs you about it, and you then want to go and fix the programming error that caused it.

There is no point in handling a runtime exception programmatically (other than reporting it) because if it is ever encountered, you will fix the error that caused it, so it should never be raised again. If you catch Exception, you run the risk of handling runtime exceptions in the same way as checked exceptions, which is almost certainly incorrect.

So if you really have to catch Exception (this is highly discouraged), you should first catch RuntimeException and rethrow it:

catch(RuntimeException re)
{
throw re
}
catch(Exception e)
{
…some logic…
}

Of course in most systems that are in production, instead of allowing a runtime exception to bubble all the way up, which would bring the system to a halt, we want to catch them at the top of our exception handling structure, and inform interested parties about it.

If we apply the Fundamental Pattern of Exception Handling, there is only one point where exceptions are handled, so it makes sense to catch runtime exceptions as well, but we want to handle them differently from checked exceptions. I guess pointing this out was out of scope for your post.

What are your thoughts on the two reasons I mentioned for not catching Exception?