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.
