From the article: "With the hindsight of a decade, we can see that it’s a disaster. The trouble is that every time you call a method that throws an exception, you create an immediate crisis: you break the build. Rather than conciously planning an error handling strategy, programmers do something, anything, to make the compiler shut up."
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.
"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."
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.
It depends on what kind of application you're talking about. When I think of hordes of crappy Java programmers, I think of enterprise web apps schlepping around business data. In that case, I think it's better to corrupt a few orders than to have hours of downtime every week.
Yeah, nothing is better than a whole lot of corrupt business data! It's so much better to have the system not crash than collect incorrect money amounts or send 10 million unpaid widgets out.
When an exception occurs and the system goes down, you get a nice notification and a stack trace. From there you can actually go about fixing the problems created by those hordes of crappy Java programmers rather than just ignoring the problem and hope that nobody will notice.
"The trouble is that every time you call a method that throws an exception, you create an immediate crisis: you break the build. Rather than conciously planning an error handling strategy, programmers do something, anything, to make the compiler shut up."
Now, granting that people like that are even paid to write code, do you think they're allowed to work on systems that ship widgets or cause money to change hands?
Frankly, we're having an absurd discussion because the assumption introduced by the original article is absurd. Nobody programs that way, or rather the few people who program that way can't be made productive through any means short of torture.
Web applications should generally have some sort of generalized handler around the entry point that sends back a web page saying "Something went wrong and we didn't know what else to do, so we're showing you this error page. HTTP status code 500." Production software should generally log a stack trace rather than simply crashing, but checked exceptions make it harder to do that.
A 500 error is a complete outage for every affected page. Most web app pages contain a lot of boilerplate -- headers, graphics, navigation elements, footers, and so forth, so a single error in a trivial component can cause an outage for an entire application unless it is localized properly.
Imagine following example: you signed contact to guarantee 99,999 uptime - 8-9 hours of downtime per year. First your downtime is 12 hours. Now you need to work more than 1 year without any errors. Any "500" error code can cost hundreds of thousands of dollars.
How you will do error handling and exception handling in that case? If there 1 chance per million that something will work incorrectly due to solar radiation or power fluctuation, how much such temporary failures you will see when your system handling more than 100 millions of requests per day? If you restarted database and all connections to database are broken, should all your current users see 500 error code?
PS.
That is real story. ;-)
PPS.
I used RecoveryManager to handle errors in the my system. It is very simple: when it receiving an error, it uses it configuration to determine action to take (e.g. call helper method) and responding to caller with code to indicate what caller should do: throw exception to higher level or just try again for few times.
"checked exceptions actually help you out quite a bit, because you don't have a problem with stray exceptions taking down entire subsystems"
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.
You're correct, the right way to handle exceptions is to catch them in the right place so the right "unit of work" fails -- that's exactly what the article author describes. However, he argues that many programmers are too lazy or stupid to do that in the presence of checked exceptions.
"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.
"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."
LOL
Actually the software I work on is web based business software. I sincerely hope that I don't cause the sort of problem alluded to in TFA.
The fact that checked exceptions make it harder to do the right thing I guess is exactly the point. An exception is a method for forcing an abnormal program flow, and the checked exceptions reduce this to an error return mechanism. You end up with the worst parts of exceptions and error returns -- way to go!
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.