This example refers to the API of java.net. As the API-Designer does not know in which context you will use the API this checked exception make sense. In your this case it is a constant in other cases the input comes from a user. As a user input it is an recoverable state. The user can be informed that the entered URL is incorrect and he must enter a correct one.

The API abstracts fully about low level exceptions. They may be raised like a broken connection but they are not visible to the caller because he would not be able to recover from this. So they are RuntimeExceptions.

I think this is a proper view on checked exception and I agree, that not every programmer is able to see the different semantics and at last the correct conclusion. Sometimes it is a kind of tricky…

The fact is simple in that it is too primitive a tool that cannot cope with higher-level algorithms.

try {
MessageDigest md = MessageDigest.getInstance(“MD5″);
}
catch (NoSuchAlgorithmException nsae) { throw new RuntimeException(nsae); }

Here, I’ve _explicitly_ specified my message digest, and since I’m not planning on distributing this, but only running it on our public webserver, I’m never going to be running it where the security manager _doesn’t_ have MD5 sum. Yet, no, _maybe_ somehow mysteriously MD5 will be missing, so I guess I better catch that… But, that’s not as bad as this next one.

try {
URL u = new URL(“http://www.yahoo.com/”);
}
catch (MalformedURLException mue) { throw new RuntimeException(mue); }

That URL is _static_. Maybe I’m retrieving a feed from somewhere, I don’t know. But, the URL is _unchanging_, and is _not_ dependent on any user input. _WHY_ must I catch “malformed url exception”?? What am I to do with it? I guess I’m protecting myself if the URL spec changes in the future?

I’m with Squirrel up there. For the most part, if an exception is thrown, I really can’t do anything about it, and all that the mandatory checked exceptions get me, is code bloat/cruft.

The above argument works against the need for checked exceptions as well. Afterall, you need good programmers and good APIs thus there is no need for language level things like checked exceptions to protect you from bad designs and programmers.

This argument holds no weight in the real world where no API is perfect and no programmer is either.

These provide a way to handle runtime exceptions in a custom way (file logging, dialog, etc…).

“Use checked exceptions for recoverable conditions…”
What percentage of the Exceptions in your code relate to a recoverable conditions? I maintain a large webapp, and my personal answer is “very few, maybe none”. I want to handle errors, I really do.

“and runtime exceptions for programming errors”
Runtime Exceptions have a very big problem – they produce awful stack traces. Checked exceptions, used properly, get caught and wrapped at every level of the call stack, and end up providing all kinds of juicy data when you are reading over the stack. Why should programming errors have awful stack traces? They’re way more common than recoverable problems, and just as import to diagnose.

I don’t have any great solutions, just wanted to point out I rarely see opportunities for meaningful recovery, and that I hate stack traces caused by RuntimeExceptions slipping up to the top of the call stack w/ no chaining.

Thanks for your comment. You raise a great point about documentation: even with a lot of effort, the docs will still get it wrong. The only way to get them write is to have them verified automatically – which you get for free with a checked exception.