http://constv.blogspot.com/2009/08/error-handling-and-exceptions-in-java.html

Cheers,
Alec

My two cents also as a blog entry (I am favoring unchecked exceptions only approach):
http://www.aldana-online.de/2008/07/28/getting-rid-of-checked-exceptions-in-java/

3 and 4 cannot always be resolved, and they’re usually *not* related to SQL at all. The same issue occurs with checked IOExceptions – generally, if you try and catch an IOException upon close, and one actually happens, normally, there’s nothing you can do about it – and who cares, because you’ve closed the resource and shouldn’t use it again anyways!

RuntimeExceptions, such as those used by Spring, are much more informative, and the best part is that they are optional. If all the exceptions were optional, you probably wouldn’t have the problem of naive programmers doing a try-catch and squeltching an exception at an inappropriate time. Checked exceptions force you to handle them, but as for your “Customer” method – why care about the internals? You could have a checked or runtime exception, but then every time you have to retrieve a customer you have to try catch. If you just throw a runtime exception, you’ll have the same information as a checked exception, and no one will make empty try catch blocks because they get annoyed at having to try-catch all the time (it does happen, although I generally log exceptions or place comments saying that they were intentionally ignored).

The most basic problem with checked exceptions, though, is not that they’re checked – it’s that the exception that is thrown from Java’s checked exceptions often has *nothing* to do with the actual problem – you have to dig deeper into the exception. Specific RuntimeExceptions are more easily caught when you *can* deal with the problem, and just as easily ignored when you cannot (if your customer processing method can’t get a customer, what should it do? Catch and then return, or throw the exception? I would just throw the exception, because then something would be wrong that the customer processing method cannot do anything about – and that’s what runtime exceptions do for you by default).

Using DaoException has no much sense – it doens’t say anything, just that method can throw exception, which is known just by definition. But it adds lots of pain in neck for guys who have to think what to do with it next – add to throws or wrap with another or anything else…

Hope it helps :)

The page you mentioned above is about the new design by contract features in .Net. This DbC stuff, along with automated test case generation (see the Pex tool demonstrated in the video), really looks promising, and I strongly believe that this is where we’re heading.

Compared to DbC and Pex, checked exceptions seem to be a quite primitive and inconsistent “feature”. Consider this:

private static final URL namespace = new URL(”http://example.com/specs/2009/etc”);

This code is simple, concise, and – as far as the JVM is concerned – correct. However, the java compiler will report an error due to the checked exception declared by the URL constructor. Let’s try to “fix” it:

private static final URL namespace;
static {
try {
namespace = new URL(”http://example.com/specs/2009/etc”);
} catch (MalformedURLException mue) {
throw new AssertionError(”unreachable”);
}
}

Adding those seven (!) lines of code solved the compiler issue, but now it is impossible to achieve more than 33% code coverage in regression tests, because the exception handler code can never be reached. Code coverage essentially becomes useless as a quality measure – if I get less than 100%, I’ll never know if I missed something in the unit test, or if it’s due to some darned unreachable checked exception handler. (But why bother writing unit tests at all, the compiler already told me that everything was fine, right?)

There are many more examples where checked exceptions force you to write unreachable code (String.getBytes(”UTF-8″), MessageDigest.getInstance(”MD5″), all uses of ByteArrayInput/OutputStream or StringReader/Writer…). In a language that otherwise reports unreachable code as errors, this has to be considered a bug in the language design.

In .Net 4.0, with a tool at hand to automatically devise test cases that cover all branches in the code (such as Pex), there is clearly no need for a feature that introduces unreachable code as a side effect (however promising the concept may sound in theory).

I really would like to see things like DbC and Pex in Java. However, considering how many people still believe that checked exceptions are a good idea, I don’t think that it’ll happen soon…

1) There’s no reason you can’t declare the throws clause on the method signature when using unchecked exceptions.

Customer getCustomer(CustomerId id) throws UncheckedDaoException;

Your method signature is now self describing and hides no details.

2) Based on the lazy/incompetent programmer scenario, I’ve seen *lots* of code that deals with exceptions by bubbling them because the code doesn’t know how to handle them.

void Foo() throws MalformedUrlException, FileNotFoundException, ClassNotFoundException, SomeCustomApplicationException {
// Crazy logic goes here.
}

Later, one of those aforementioned programmers sees that ugly mess of a throws clause and decides to clean it up:

void Foo() throws Exception {
// Same crazy logic goes here.
}

Ah, much cleaner. Unfortunately, it now tells me exactly as much information as:

void Foo() {
// Same crazy logic goes here.
}

And if that doesn’t happen, invariably the aforementioned programmer will code the caller in this fashion:

void Bar() {
try {
Foo();
}
catch(Exception e) {
// “Handle” error here.
}
}

Again, we have a situation where a generic catch all is happening when it shouldn’t be. What happens if Foo throws an IndexOutOfBoundsException? This is very likely a programming error and not simply something that we can “handle” and move on.

One of the funny arguments is that you do not need to pollute you code with infrastructure errors that are rare to happen, well if you stay long enough to see life in production you’ll discover that they are not as rare as you thought. And guess what, The end user “catches” the exception instead of the developer, with sometimes some pretty sensitive information passed even through the World Wide Web!
Well, now with a good design, knowing at compile time that you need to handle the infrastructure errors, you create your own “infrastructure checked exception” where you wrap the kind of exception hiding sensitive information and logging what has to be logged. This way you are sending a message to the user of your service that, there is an infrastructure behind that can fail, and that he needs to think about represent the case for his service user, and so on. This is for a healthy architecture that does not delay production problems until production because they tend not to happen in dev environment.

In the same way, I don’t see how this can affect encapsulation, again in some often mentioned examples, of one file based logging, and another database log. Well you need to do an abstraction which is a logging exception that wraps logging infrastructure errors. And Checked Exceptions will help me to make sure that the end user will not receive a Logging Exception kind of error!

versioning is the same issue as in any type in the contract. I don’t guess a java programmer will change to return an int instead of an Integer because he decided. This is not an issue of Exceptions but rather a normal problem of Producer/Consumer design that you have even in dynamic languages.

I seriously think that J2EE, with the effect of mainstream frameworks, abandoned Java Checked Exceptions way too often.