Dan S continues the discussion:
Though I agree that "exceptions" were meant to move away from return codes by "centralizing" the error handling, I disagree with your definition of "centralize."
How can you do that, when I didn't give one?


Checked exceptions merely provide compile-time checks on error handling.
There's checks and there's checks... Checked exceptions don't "merely" provide "compile-time checks on error handling", they provide paranoid, self-contradictory, concept-defeating compile-time checks on *EVERY STEP BETWEEN* error and handling.


They are neither good nor bad, but act as a tool by developers.
No, they are bad, because they act as _a hindrance_ to developers.

I mean, heck, this is a _fact_, attested to by heaps and reams of evidence all over the Net. (Sure, you may want to call that evidence "anecdotal"... But isn't all evidence "anecdotal", in a way? Doesn't it become a little less "anecdotal" [as in "of no consequence"], when it includes *your own* observations? It sure looks like more of a fact than do the misguided *intentions* of Java's designers, at least.)


They force developers to *think* about exceptions by forcing them to make the compiler happy.
No, they obviously don't -- what they *really* do is: They force developers to *catch* a lot of exceptions to make the compiler happy, which leads to UN-thinkingly catching (often, just to "swallow" and forget) TOO many of them.

You might want to blame that on the developers, but:

A) It's a perfectly natural "path of least resistance" reaction to an overly restrictive system,

B) this reaction seems blindingy obvious (at least to me, but I have to admit I wasn't there when Java was designed), and as such should have been easily predictable,

C) so in total, they DON'T lead to what you claim they were intended to lead to, but rather the opposite.

Ergo, they don't work.

(Yeah, it's really that simple: They just don't work, in the real world outside Gosling's beard.)


Centralization requires a definition of what central is (that is, define the point). If centralization means a particular "layer" within code, so be it. If it means the main thread of execution, fine. For GUI applications, it may mean pushing the original exception up the stack far enough to display to the user. In a batch system, where there is no user, that central location may be completely different. It's a question of where (locality).
No, it is NOT "a question of where (locality)", and no, 'centralization' in and of itself does certainly NOT require a definition of "what central is".

Centralization is a *concept*, an *idea* -- exactly *what* point ("locality") you center on, is implementation-dependent and doesn't matter for the concept per se. That is, exceptions were supposed to let you have your error handling at some *arbitrary* central point *of your choice*.

The point (of my argument, not the central one we talked about above) is, exceptions were supposed to let you handle your errors at this arbitrary central point of your choice, WITHOUT having to touch all OTHER areas of code in between where the error occurred and where it's handled.

Once you defeat that, you've *defeated the whole idea* of exceptions, and can just as well go back to return codes -- because you've just re-created them, only bloated by several orders of magnitude.

How can you *not* see this?!?

Or, if you still want to claim there's a difference: Could you explain *exactly* what it is, "as if to a four-year-old"?


I think a better argument against checked exceptions is how they provide a capability that is not easily handled by unchecked exceptions.
Huh?

If they actually provided any capability that other systems don't, wouldn't that be an argument FOR them?


Again, it comes down to providing a compile-time check. I understand that many here prefer run-time checks rather than compile-time ones. I think that more a taste, and I have no issue with that.
Heh -- yeah, I'm well known here for my anarcho-libertarian preference for run-time checks and aversion to compile-time ones... Sorry, but more seriously, *that* kind of compile-time checks isn't the only one there is.


My only real argument is that checked exceptions work well in certain circumstances and that I've found them useful.
Hmm, yeah, well... Hard to argue with experience. (If you're *sure* you haven't somehow deceived yourself into thinking so? :-)


However, I heartily agree that they have been misused, especially in the core JDK libraries. This has given them a bad name. It's a question of well designed use.
I think "well designed use" of a mis-feature is a contradiction in terms.