It is tedious to HAVE TO do it.

It CAN BE useful to wrap and contribute some contextual, runtime information to the stacktrace.

It IS unnecessary because you can use unchecked exceptions instead.

catch (SQLException ex) {
  throw new DomainModelException(ex);
} 

is tedious and unnecessary.

For further payoffs, provide an additional message in the new exception, containing some contextual information relevant to the situation. Keep in mind that more information exists at runtime, and all too often I see static exception message strings thrown from, say, lookup-foo-by-name type methods, simply: “Unknown foo”. What a senseless waste of human life! How many man-hours could not have been saved, if the author instead had given us the string “Unknown foo ” + name?

The runtime perspective is a good thing, and helps me produce transparent code that can tell me about errors and help me find its right shape. I fear the static perspective - including trying to predict errors with exception checking - is confusing and may suggest, e.g. to people learning Java, that this practice is somehow “illegal” design-wise. I have been met with the argument, particularly from recovering C++ victims - that wrapping the lower-level exception will “reveal” the implementation.

One thing that should NEVER be done in production code (quite frankly, not even in test code or whatever code - I see that sadly all too often and has caused a lot of grieve) is given by the example in Elliotte’s code snippet that illustrates how to encapsulate domain specific exceptions:

try {
  someDatabaseAccessingMethod();
} catch (SQLExcepiton ex) {
  throw new DomainModelException(ex.getMessage());
}

ex has to be passed along as an exception cause inside DomainModelException.

The code snippet needs to read as follows:

try {
  someDatabaseAccessingMethod();
} catch (SQLExcepiton ex) {
  throw new DomainModelException(ex);
}

I would put the former code snippet as an example of antipattern number 1 in the list of Java antipatterns.

http://www.artima.com/forums/flat.jsp?forum=270&thread=207358#269379

In brief, a checked exception is part of the status information (success/fail, diagnostics) passed from a routine to the calling code, and so it’s legitimate to have to declare it. If not an exception, it would be an extra status parameter or return value, which would also need to be declared. Think of an exception as an “invisible return parameter”.

Unchecked exceptions a very much like gotos - untraceable execution/data paths. I find it odd that they have so many defenders.

But it does bring me onto the next objection I have about checked exceptions. The following is a re-hash of my postings in your previous thread on exceptions, but the gist of it is, that you will eventually end up with ALL methods declaring that they throws DomainModelException. This is nice from a design point of view, in that each layer will have its own exception (super)class, dutifully declared in every method.

However, I find that this practice doesn’t provide THAT much more information than NOT having that throws in every method. What it does provide though, is the need for duplicating that particular try/catch/throw construct in most (if not all) method calls going down-layer, in all layers. This is a high cost, and the information gain is low.

And when you look at what comes out, in the end, when something fails and assuming one follows your practice of using e.getMessage() for the message - what information does it contain? It has exactly the same information as an unchecked exception thrown at the original cause would have had, it just has a lot more noise. And yes, it should be handled, no rugsweeping here, no sir - but just because it’s important doesn’t mean it warrants superfluous effort.

I am trying to put this simply. I know I should give up and get on with the coding

And of course throwing an unchecked exception doesn’t mean don’t document it anywhere. If your method might throw an unchecked exception, you need to let the calling method know through the javadoc so it will be able to make that decision.

Forcing methods to deal with exceptions they cannot handle will result in one of three things: empty or nearly empty catch blocks as described by Igno (and in my experience, that happens a lot), throws clauses that grow exponentially as more and more methods get called like I described in my first post, or wrapped exceptions that just results in the obfuscation of the original, useful exception. When something happens like a resource is missing, often the only thing they can do is have a top level method (the container or shell or GUI or whatever) log the exception and print out an error message.

Also, it may be nitpicking, but I disagree regarding when Errors should be thrown instead of Exceptions. If you can handle it 10% of the time it should probably be an unchecked exception, as Errors are (almost) never handled. Something like an OutOfMemoryError cannot be handled even 10% of the time; if the system ran out of memory, then your app is pretty much hosed. The only Error I can think of offhand that can be properly handled is a StackOverflowError since they are often thrown by recursion gone bad.

I’ll have to reread Bloch, but I think what he meant was not whether the calling method could be expected to handle it, but whether any method in the call chain could (and if he didn’t mean that, he should have). There are cases such as OutOfMemoryError that really can’t be handled properly 90% of the time. These are represented by errors, not exceptions (either checked or runtime) and they’re very uncommon.