I don't have a problem with the "concept" of checked exceptions. I have a problem with the reality of how they are implemented in Java. The gist of the situation is - more cost than benefit.
You can chalk it up to laziness, ignorance, etc. But the fact is Checked Exceptions has led to a bunch of bad code. When you put too much onus on a developer to go thru a bunch of BS, they bypass it. And you hit this point "Here is what most people fundamentally don't understand about checked exceptions: they are rare. Most of the exceptions are not recoverable, so they should be unchecked. " They are rare? Well maybe they SHOULD be rare, but they aren't. SQLException certainly comes to mind. 99% of the time you hit a SQLException or IOException you can't do anything to solve the problem. They are almost always either a system problem or a bug. Either way it's not recoverable, so they should be unchecked. But they aren't, so as a developer you have to deal with the BS surrounding Exception handling. They should be runtime and bubble up to the top of the thread where the user is alerted or the transaction failure is logged. But most people write an exception handler and log it and continue as if a transaction was successful. So the intent of checked exceptions - letting the user write more robust/higher quality code has actually resulted in lower quality code. You are talking theory - I'm talking reality. I think the reason that languages with Runtime Exceptions only (in other words, every language other than Java) don't suffer is because of what you just hit on - the need to recover from exceptions is rare. So in this rare case, your testing may reveal a scenario where you want to recover. When this case is found you go in an add in your handling. Or usually it's obvious. When you are writing SQL code, you know there could be a failure and think through whether you should deal with it. Same for File/socket IO. This all being said - I think Reinier's suggestion has merit. On Sep 21, 2:41 pm, Cédric Beust ♔ <[email protected]> wrote: > On Tue, Sep 21, 2010 at 1:32 PM, [email protected] < > > [email protected]> wrote: > > Sweet! The checked exceptions debate again! > > > 1) checked exceptions are just a huge PITA. And being a huge PITA > > they lead to bad code. Java code is the worst offender for stuff like > > try {} catch(Exception e){}. How many open source libraries do you > > see every API method having a Throws Exception clause? Why do you > > think this is? > > This comes from either a bad use at the call site or at the receiver site, > it doesn't invalidate the concept of checked exceptions. > > This concept is: "If you use this API, be aware that it can fail in the > following ways, please make sure you cover all these cases before moving > on". > > I really have a hard time believing that so many people don't agree with > this simple mission statement. > > > 2) checked exceptions don't scale. If you use exceptions as intended > > (usually letting them bubble up) you end up with monster throws > > clauses. And one change to a core library can have literally 1000s of > > methods impacted. So what do people do? They swallow them, or log > > them and continue as if everything is great even though something > > failed (see point #1) > > See my response to point#1. > > > 3) Why is it that every other language ever created doesn't have > > Checked Exceptions (including Java FX)? > > Laziness, refusal to actually ponder what checked exceptions do or necessary > sacrifices to backward compatibility (e.g .Net). > > > 4) Checked Exceptions pollute interfaces. If you have a public API > > Interface and want to introduce a new checked exception you break all > > users. So what do people do? "throws Exception" or use > > RuntimeExceptions. So they bypass Checked Exceptions. > > If you modify a method that previously could fail in only one way but can > now fail in two ways, you *do* want to let your users know about it. > > If you agree that removing a method from an interface is a breaking change, > then you have to agree that adding a failure path to a method should also be > a breaking change since both will lead to crashes in production. > > Your solution of simply ignoring the new errors only leads to fragile code > bases. > > -- > Cédric -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
