Is it bad practice to catch RuntimeException for logging purposes?

Question

I've come across the fact that catching RuntimeException is generally considered bad practice because they can't be corrected and usually are programmer errors.

However, we have an (insanely) large application where changes in any part can have unforeseen consequences (Yes, this a problem in and of itself).

Now the idea has come up to start catching and logging RuntimeExceptions at the application's top level so we can be more efficient in fixing such bleed issues as they come up.

Like every good Java team, we have a lovely zealous Uncle Bob follower who is absolutely forbidding us from doing it.

How bad is it really to do this? Are there really no cases in which this is okay or even recommended?

Sidenote - zealotry helps no-one in software development. Make sure your co-worker actually articulates *why* they think this is a bad idea, rather than "Uncle Bob said so!". — Joe Clay, Aug 10 '17 at 08:14
Nothing is stopping you from catching an exception do your logging and then rethrow the exception. Maybe even wrapped in another exception. This is more of a discussion than an appropriate question for SO. — Daniel Figueroa, Aug 10 '17 at 08:15
Sometimes, logging an exception is the body of your catch. Just be sure that whenever you catch a runtime exception, if you don't fix it, you throw it back after. — Turtle, Aug 10 '17 at 08:15
In my opinion, the general idea of catching exceptions and "correcting them" is over-ambitious. Do it only if you are willing to bet $1000 that you've understood each and every situation that might have led to the exception. Not willing to do that? Don't catch it or rethrow it, but don't continue hoping thet you took the right correcting action... — Ralf Kleberhoff, Aug 10 '17 at 08:26

TwoThe · Answer 1 · 2017-08-10T10:54:09.993

Catching RuntimeExceptions is not a problem, they are Exceptions so they can be caught and properly processed. If the Java developers would have wanted you to not catch RuntimeExceptions, they would have named it RuntimeError.

What is bad is to catch RuntimeExceptions, discard them silently and continue to run as if nothing ever happened. RuntimeExceptions are there to notify the developer/user of critical issues and situations where the program clearly left the expected state. At a minimum this should be logged, and you should try to get the program back into a comfortable state.

If you can continue after such a major failure totally depends on your application. Web-Servers i.E. commonly catch all exceptions and errors, and just restart the appropriate Servlet so they can continue to serve requests.

Maxim Ponomarev · Accepted Answer · 2017-08-10T09:04:36.390

It's not always bad to catch RuntimeException's. But even if your team decided to not catch RuntimeException's, you can always catch it, log something and then re-throw it. It won't change your application logic at all.

Almost all logger libraries nowadays have possibility to log different details about the exception (like a stacktrace and all nested exceptions as well) in addition to log message.

public void doStuff(String param){
  try {
    process(param);
  } catch(RuntimeException e) {
    logger.error("Something weird happened while processing " + param, e);
    throw e;
  }
}

Below is an update, about the context, thank you Ralf Kleberhoff for pointing on that

It's better to log a message about RuntimeException (or any other Exception) only on a top levels of your application, to avoid duplicate messages about the same exception in the log.

If you just want to add some context (like a parameter value, as Ralf Kleberhoff mentioned) and it's not the application top level catch (and you are sure, that top level catch actually exists ), it's better to create a new Exception and add original Exception as a cause into the new one.

public void doStuff(String param){
  try {
    process(param);
  } catch(RuntimeException e) {
    throw new RuntimeException("Something weird happened while processing " + param, e);
  }
}

private void process(String value){
  throw new IllegalStateException("Not implemented yet!");
}

Gave +1. Generally, I don't like catching, logging and re-throwing exceptions because that tends to happen at multiple levels of your application, duplicating a single exception into many log entries, BUT in your example, it perfectly makes sense because you log context information (param), that isn't present in the exception itself. — Ralf Kleberhoff, Aug 10 '17 at 08:37

score 0 · Answer 3 · answered Aug 10 '17 at 08:17

0

Totally depends on the flow and where you catch it.

If you are using Spring consider writing a ControllerAdvice. read more here https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/web/bind/annotation/ControllerAdvice.html

answered Aug 10 '17 at 08:17

Phanindra Gopishetty

161
1
8

Ori Marko · Answer 4 · 2017-08-10T08:59:36.077

0

It's not a bad practice to catch RuntimeException when needed.

It can be useful when using 3rd party code which throws its own exceptions extending RuntimeException and then you need to catch it in order make a good exception handling.

Also in JSPs It's sometimes helpful to catch RuntimeException to prevent page not displaying at all because of a NullPointerException.

edited Aug 10 '17 at 08:59

answered Aug 10 '17 at 08:22

Ori Marko

56,308
23
131
233

Is it bad practice to catch RuntimeException for logging purposes?

4 Answers4

Linked