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!
"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.