Good practices for Java exceptions handling [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 8 years ago.

I have some questions regarding handling exceptions in Java. I read a bit about it and got some contradicting guidelines.

Best Practices for Exception Handling

Let's go through the mentioned article:

It states that one should generally avoid using checked exceptions if "Client code cannot do anything". But what does it exactly mean? Is displaying error message in GUI sufficient reason for bubbling up checked exception? But it would force GUI programmer to remember to catch RuntimeExceptions and their descendants to display potential error info.

Second view presented in this article is that one should evade inventing own exception classes unless I want to implement some customs field/methods in them. I generally disagree with this, my practice up today was just the opposite: I wrapped exceptions in my own exception structure to reflex goals realized by classes I write, even if they just extend Exception without adding any new methods. I think it helps to handle them more flexibly in the higher layers when thrown plus it's generally more clear and comprehensible for programmer who will use these classes.

I implemented some code today 'new way' presented in the article throwing RuntimeException here and there, then I let Sonar analyze it. To confuse me even more Sonar marked my RuntimeExceptions as Major errors with a message like "Avoid throwing root type exceptions, wrap'em in your own types".

So it looks quite controversional, what do you think?

I also heard from one of tech-leads today that just wrapping exceptions is bad, 'because it's a really costly operation for JVM'. For me, on the other side throwing SQLExceptions or IOExceptions everywhere looks like a bit of breaking encapsulation..

So what is your general attitude to questions I presented here?

1. When to wrap exceptions in my own types, when I shouldn't do this?

2. Where is that point of 'client cannot do anything about this, throw runtime exception?'

3. What about performance issues?

Answer 1

It looks like your tech-lead, as often, has escaped his role of developer because he wasn't good at it.

My advices would be:

• prefer runtime exceptions over checked exceptions, especially if you're not the only client of your API. Using a checked exception forces every client to handle the exception, even if it can't do anything about it. If this is really what you want to do (i.e. forcing the caller to handle it), then a checked exception is what you want.
• if the only thing the client can do when an exception happens is displaying a more or less generic error message such as "oops, something bad happened, please retry or go back to the welcome page", then definitely use runtime exceptions. Most of the presentation frameworks provide a way to use a generic error handler.
• definitely use exceptions that are linked to your abstraction layer. Throwing a SQLException from a high-level service is not adequate. Use existing exception types when they're appropriate (like IllegalArgumentException to signal an illegal argument). Otherwise, wrap the low-level exception into a higher-level, appropriate exception type. What is costly is to throw an exception. Whether it wraps another one or not doesn't matter much. And it should only happen exceptionally anyway.