Java – When we need to serialize an exception

1. Sometimes you want to catch a specific type of exception (e.g. MyAppDuplicateException) and sometimes you want to catch a whole category of exceptions (e.g. MyAppException). By having MyAppDuplicateException extend MyAppException you're giving the calling code a bit more flexibility in how it deals with the different exceptions.
2. The best advice I've heard on this is that generally speaking you should throw a checked exception if whatever called your method obeyed its contract. It's a way of saying "here are the things that might be expected to fail". I would definitely make MyAppDuplicateException and the like checked exceptions (i.e. not RuntimeExceptions).

There's a very good article here which should help you avoid most of the common pitfalls.

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.