CODEWITHSUNDEEP
javaexceptionruntimeexception
Weckar E.
Weckar E.

Reputation: 777

Is it bad practice to catch RuntimeException for logging purposes?

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?

Upvotes: 9

Views: 12754

Answers (4)

TwoThe
TwoThe

Reputation: 14309

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.

Upvotes: 11

Maxim Ponomarev
Maxim Ponomarev

Reputation: 159

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!");
}

Upvotes: 9

Ori Marko
Ori Marko

Reputation: 58872

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.

Upvotes: 0

Phanindra Gopishetty
Phanindra Gopishetty

Reputation: 169

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

Upvotes: 0

Related Questions