This implies that having a catch-all around your entire program is a bad idea. Doing so loses the stack trace; you no longer know where the exception was thrown from. I've had to debug programs that did this, and the first thing I did was comment out the catch all so a simple stack trace could tell me where to start looking.
In the compiler I'm writing right now, I do wrap the entire execution in a try-catch block, but the only errors I catch are ones I call "user_error". That represents an error in the input; I don't handle that kind of input on purpose, and providing it is user error, not compiler error. I don't catch the other kinds of exceptions I throw, which indicate what gcc calls "internal compiler error." It's much easier for me to figure out what I did wrong that way.
What about daemons? large batch programs? I, personally, would rather have them catch and alert(email, sms) unknown/unexpected exceptions continuing on with what they can rather than simply die.
The alternative, to continue on in an error state without knowing how it will effect execution, is worse.
Propagating errors upwards like you say breaks functionality encapsulation.
But if you don't know how to handle it, you should still throw it up, even if it breaks functionality encapsulation. This will likely crash the application, but the source of the error will be easily traceable, and the underlying problem can be fixed.
Frankly, this is the weirdest complaint I've ever seen about checked exceptions. If you're trying to build a system with crappy programmers, you're kind of screwed anyway, but checked exceptions actually help you out quite a bit, because you don't have a problem with stray exceptions taking down entire subsystems. You might miss a lot of meaningful errors and get corrupted data, but at least the system keeps running, and that's the most you can hope for if your programmers are as crappy and lazy as the article describes.
And contrary to the article, few programmers are really that lazy and irresponsible. In my experience, far more code is written by responsible programmers who are inexperienced, rushed, or lacking a complete understanding of the system. Checked exceptions catch a lot of normal programming errors and result in more error cases being handled correctly. Like any other restriction imposed by a programming language, they don't ensure perfect code, sometimes they result in busy work, and crappy programmers will find crappy ways to work around them, but IMHO they are helpful for most programmers.
What? If I'm working with crappy programmers I don't want the system to keep going and corrupting data -- in the vast majority of cases, that's the worst possible result. Taking down the system with an nice error message and stack trace is a much much better. Crappy programmers, in the presence of checked exceptions, will handle exceptions with empty catch clauses (to prevent breaking anything) and there will be no way to find that error when it happens.
Dunno about this. It's some time since I did any Java, but it seems to me that if you want to isolate a sub-system then the thing to do is to isolate it in the code explicitly where you want the sub-system isolated (i.e. like C++'s `catch (...)`) rather than force exception propagation/chaining through every function in the call chain.
I've found far more nasty problems caused by exception masking than I have by too many exceptions being thrown. I'm not sure what sort of system you might be working on where erroneous data is less of a problem than an exception.
"I'm not sure what sort of system you might be working on...."
I'm not sure what kind of system we're talking about either. Accepting the article's assumption of such stupid and/or lazy programmers, and accepting the implicit assumption that it's possible to produce useful software with such programmers, I'm guessing it's some kind of web-based business software.
What I usually do is cheat by catching the checked exception within the method, and then throw it again by using exception chaining to wrap it into an unchecked exception (RuntimeException). But it's hard to see that as a good solution.
By throwing RuntimeException you're saying "don't catch this," which I agree is a bad thing, but any other kind of unchecked exception would be just as bad. You implement a third-party interface so other people's code can call methods on your object. If you throw exceptions they don't expect, then they have no chance of catching them anyway, so what's the difference?
Checked exceptions are just another way of specifying the behavior of an object so it can be handled predictably without knowing its precise type. If a method doesn't let you throw an exception indicating failure, then the method isn't supposed to fail, or it's supposed to report failure another way. If that isn't reasonable for your implementation, then the library isn't suitable for your needs. It isn't much different from the case where a method lacks arguments that you need, or has a return type that is too restrictive for your needs. If you can't adapt your code to fit the interface, you can't use it.
... isn't this what everybody does?
Eric Lippert also provides an interesting view of the varieties of exceptions: http://blogs.msdn.com/ericlippert/archive/2008/09/10/vexing-...
If you follow the philosophy of this article and classify exception's as Eric suggests, you should be in pretty good shape.
