Comments on: Old News: Java Checked vs. Unchecked Exceptions

By: kriggio

kriggio — Thu, 31 May 2007 19:10:49 +0000

In response to the link Josh provided, Closures != Checked Exceptions, nor are they a suitable substitute. Egads, this would be a disaster.

By: Josh DeWald

Josh DeWald — Thu, 31 May 2007 16:56:12 +0000

Thought you might find this of note:

http://weblogs.java.net/blog/editors/archives/2007/05/reflection.html

By: quellish

quellish — Sat, 26 May 2007 07:28:34 +0000

Exceptions were a good idea!
On paper. In reality, they are probably the most misused part of the Java language I’ve seen, and the biggest failure of java as a programming culture. Exceptions didn’t really work past the early revisions of java - as applications became more complex, error handling and exceptions became MUCH more complex. And no one really said “Hey, this wasn’t the greatest idea in practice, we need to rethink this” and deprecate exceptions.
Nope.
Now we have layers on top of, or in parallel to, exceptions that largely make the problems worse.

In a real world app, you’re often better off reinventing the wheel and rolling your own error event handling.

But hey, people also put objects in databases. *shakes head* .

Arent we as engineers supposed to be making things simpler, not more complex?

By: Josh DeWald

Josh DeWald — Thu, 24 May 2007 10:25:27 +0000

I think we’re all just lazy in practice. I always intend to go back and “elegantly” handle the exception but my initial coding foray is always the “happy path” which leaves no room for exception handling. But then naturally the code gets deployed with a bunch of “printStackTrace()” messages (I *never* swallow and exception at least). It really gets bad if the method in question is a void, the caller has *no* idea that things failed. So at the *least* I will return false in those methods when I catch the exception. I think there are times when this is the correct response (if you’re the end of the line, and the caller of you isn’t expecting any exceptions, just true/false). But it’s not when there’s a complex chain of method calls and one of them selfishly takes the Exception and does nothing with it, providing no information to upstream callers.

So I guess my point is that I agree with you Ken, but as with many developers, I find myself not elegantly doing the error checking and processing for non-trivial callstacks (especially relevant for GUI code). And I can’t claim to not have read a lot of articles similar to yours about the importance of them.

By: Repete

Repete — Thu, 24 May 2007 06:26:43 +0000

I’d have to say checked exceptions, in practice, cause more problems than they are worth. The “worst case scenario” you show there is precisely why I don’t like checked exceptions. That code is more common than it should be and sometimes results in quiet failures. Also, another problem with that code is it will swallow runtime exceptions too, hence breaking the whole idea of runtime exceptions all because a developer is lazy. Once again this is in practice so you can blame the developer there I’ll give you that. If Java must have checked exceptions I would suggest making a checked exception superclass so developers can still be lazy without “clobbering” the idea of runtime exceptions; but that is still a compromise. I don’t see harm in removing checked exceptions because RuntimeExceptions can still be handled so all we are really losing is the “… eloquently documented…” exceptions. This documentation of exceptions causes a lot of extra code to be written and, in my experience, largely not handle the exception in any meaningful way other than directing a user to a “pretty failure” screen.