Java Exception Handling – Checked vs Unchecked Exceptions

Checked exceptions are a failed expriment in language design. They force you to have extremely leaky abstractions and dirty code. They should be avoided as much as possible.

As for your points:

1) Checked exceptions make the code dirty, and no less unpredictable because they show up everywhere.

2) How is a checked exception being shown to the user any better? The only real difference between checked and unchecked exceptions is technical and affects only the source code.

3) Ever heard of stack traces? They tell you exactly where the exception was thrown, no matter whether it's checked or unchecked. Actually, checked exceptions tend to be worse for debugging because they're often wrapped which leads to longer and uglier stack traces, or even lost atogether because the wrapping was done wrong.

There are two kinds of exceptions: those that occur "normally" and are typically handled very close to where they occur, and those that are reallly exceptional and can be handled generically in a very high layer (just abort the current action and log it / show an error).

Checked exceptions were an attempt to put this distinction into the language syntax at the point the exceptions are defined. The problems with this are

• The distinction is really up to the caller, not the code that throws the exception
• It's completely orthogonal to the semantic meaning of an exception, but tying it to the class hierarchy forces you to mix the two
• The whole point of exceptions is that you can decide at what level to catch them without risking to lose an error silently or having to pollute the code at intermediate levels or ; checked exceptions lose that second advantage.

I'm going to assume that there are situations where it is reasonable to throw exceptions.

I'm also going to assume that this is a situation where it is reasonable to use exceptions. (The fact that this is "internal" to your code does not alter this. And you cannot reasonably infer that exceptions are in appropriate based on the proposed exception name ... @Jarrod Roberson note!)

So the question is whether it is reasonable to declare a private exception class. To that I would say "Yes", assuming that there is no existing exception class that is suitable.

The only riders I would make is that if there is any chance that the exception might "leak", then:

• you should declare a constructor so that the exception has a reason String, and
• you should declare it as public ... so that any javadoc for the exception appears in the published API documentation.