You have to balance benefit/cost
Do you use goto extensively? Why or why not?
Yet the fact is that goto is only harmful when misused. As Knuth famously pointed out in a paper devoted to the subject, goto has legitimate uses within structured programming. (At least in languages like C which do not have labelled loop control.) Why then do people generally discourage its use so strongly?
You use the example of Perl being bad. It is a truism that it is really easy to code unmaintainable code in any language. It is obvious that Perl has a poor reputation in this way. However Perl also has an excellent reputation for resulting in good productivity. And Perl certainly has been an effective tool for a lot of people. It has costs and benefits. Sometimes it is worthwhile, and sometimes it isn't. Choose wisely for your situation.
You use the example of inheritance being bad. The same thing holds. There is a skill to design, and people only learn what the problems are by making mistakes. It is obvious that there are benefits and costs of inheritance and make a case for when it is appropriate.
So far I am speaking in truisms. So it is a truism that the same must hold for checked exceptions. As I pointed out in [link|http://z.iwethey.org/forums/render/content/show?contentid=118648|http://z.iwethey.org...?contentid=118648], the benefit as I understand it to checked exceptions is that it makes it easier to prove that you have accounted for every possible exceptional case somehow. If that is your primary goal, and the goal of your whole team, then I'll buy that checked exceptions could be worthwhile.
But checked exceptions are in the (very long) list of technologies that require extra work from users to solve a problem that most of them don't care about. Every last one of those technologies - checked exceptions included - runs into constant problems as users set out to satisfy their goals and therefore shortcut on the extra work in the most convenient way possible. Which, in the case of checked exceptions, is going to mean that errors get swallowed from time to time.
The vast majority of programmers need to make some pragmatic tradeoff between things like bugs, development speed, the ability to make random changes later, etc. Statically proving at compile time that every i is dotted and t is crossed in all possible exceptional circumstances is rarely anywhere near a top priority. It certainly is lower than guaranteeing that code does what it is supposed to do in response to different kinds of user input.
If you are, or you work with, programmers who do not prioritize what checked exceptions can do for you, then they are not going to be worthwhile. More than not just being worthwhile, but people working around checked exceptions to satisfy their personal goals is likely to lead to poorer satisfaction of my goals. I think that this clearly covers most of us.
So, except for a vanishingly small fraction of programmers, I do not see that checked exceptions are worthwhile.
Cheers,
Ben
