When is it OK to catch a RuntimeException

Question

On a recent project I recommended catching a RuntimeException within a test harness code and logging it. The code processes a series of inputs from a database, and I do not

Answer 1

Personally, I've always been told that you want to catch all RuntimeExceptions; however, you also want to do something about the exception, such as running a failsafe or possibly just informing the user that an error occurred.

The last Java project that I worked on had a similar approach, at the very least, we would log the exception so that if a user called complaining about a bug, we could find out exactly what happened and see where the error occurred.

Edit 1: As kdgregory said, catching and ignoring are two different things, generally, people are opposed to the latter :-)

Answer 2

Years ago, we wrote a control system framework and the Agent objects caught runtime exceptions, logged them if they could and continued.

Yes we caught Runtime exceptions including OutOfMemory in our framework code( and forced a GC, and it's surprising how well that kept even quite leaky code running.) We had code that was doing very mathematical things involving the real world; and from time to time a Not-A-Number would get in due to tiny rounding errors and it coped okay with that too.

So in framework / "must not exit" code I think it can be justifiable. And when it works it's pretty cool.

The code was pretty solid, but it ran hardware, and hardware tends to give screwy answers sometimes.

It was designed to run without human intervention for months at a time. It worked extremely well in our tests.

As part of the error recovery code, it could resort to rebooting the entire building using the UPS's ability to turn off in N minutes and turn on in M minutes.

Sometimes hardware faults need to power cycled :)

If I remember, the last resort after an unsuccessful power cycle was it sending an email to it's owners, saying "I tried to fix myself and I can't; the problem is in subsystem XYZ", and included a link to raise a support call back to us.

Sadly the project got canned before it could become self aware :)>

Answer 3

In my code 99% of my exceptions are derived from runtime_exception.

The reasons I catch exceptions are:

• Catch Log and Fix problem.
• Catch Log and Generate a more specific exception and throw
• Catch Log and rethrow.
• Catch Log and Kill operation (discard exception)
  • User/request initiated action fails.
    An HTTP request handler for example. I would rather the requested operation die rather than bring the Service down. (Though preferably the handler has enough sense to return a 500 error code.)
  • Test case passed/failed with an exception.
  • All exceptions not in the main thread.
    Allowing exceptions to escape a thread is usually badly documented but usually causes program termination (without stack unwinding).

Answer 4

You catch RuntimeExceptions (in any language: unexpected exceptions/“all” exceptions) when your program is doing multiple subtasks and it makes sense to complete every one you can rather than stopping on the first unexpected situation. A test suite is a fine situation to do this — you want to know which of all the tests failed, not just the first test. The key characteristic is that each test is independent of all the others — it doesn't matter whether a previous test doesn't run because the order is not significant anyway.

Another common situation is a server; you don’t want to shut down just because one request was malformed in a way you didn't expect. (Unless it’s really, really important to minimize the chances of inconsistent state.)

In any of these situations, the appropriate thing to do is log/report the exception and continue with the remaining tasks.

One could vaguely generalize to any exception: it is “appropriate to catch” an exception if and only if there is something sensible to do after catching it: how your program should continue.