There's middle ground. It's quite simple, even: Give any code the
opportunity to explicitly state that it does not want to handle a
checked exception. In other words, you say: Yes, I know, I should
handle this IOException. I don't wanna. Go away. And the compiler
stops whining about it. The IOException isn't wrapped up in a
RuntimeException, and methods higher up the stack can catch it if they
want to.
This is good for a number of reasons:
A: It gives programmers a way out when their particular use case
doesn't fully match an otherwise perfect API's designs: No matter how
nice and careful you design your checked exceptions hierarchy, there's
always going to be a situation where a checked exception fails the
checked exception test: They should be both expectable (i.e.
UnsupportedEncodingException is not expectable when you're hard-coding
your encoding as UTF-8, which the JVM spec says must be supported.
Conclusion: This API sucks) and reasonably handleable (i.e.
IOExceptions are to be expected when working with servlet streams,
but, there's not much you can do about it in most cases. The last
thing you want to do in such a situation is to "handle" it yourself by
logging and ignoring it. You should let them percolate up the stack,
but if the API won't let you because of signature restrictions, that
API sucks, because its forcing you to rewrap into RuntimeException.
Example: Runnable's run method).
B: It gives programmers a way out when dealing with a badly written
API. We don't live in a perfect world. Making do with a less than
optimal library happens all the time.
The problem with the 'expectable and handleable' test is that these
are moving targets and no API is going to magically guess the right
answer for all possible use cases of that API. What's perfectly
expectable in most situations (IOExceptions when reading from an
InputStream) becomes an unexpected problem when you're using
Class.getResourceAsStream (if, after successfully opening a stream
that way, that stream throws an exception, then this is as likely to
occur as one of the classes you're using failing in the same way,
which would cause an obscure Error, not even a RuntimeException. *NOT*
bothering with IOExceptions falling out of such a stream is perfectly
allright, so long as, if they do happen, you percolate up some sort of
exception and you don't just silently swallow them). You can try but
I'm convinced its not possible to produce a perfect API that always
guesses right.
One simple answer to all this is indeed to say: Well, checked
exceptions are a lousy idea. We should just dump em.
But that's perhaps going too far. Instead, when a programmer is
confronted with a checked exception, and the programmer explicitly
confirms that this particular checked exception is either not
handleable or not expected in this particular use case, he can do so
with no fuss and without mucking up the percolating exception by
wrapping it or otherwise contaminating the stack trace.
Something like a "sneakythrows" in addition to the usual "throws"
could do it:
public String fromUTF8(byte[] bytes) sneakythrows
UnsupportedEncodingException {
return new String(bytes, "UTF-8");
}
incidentally, project lombok support this. The only difference: You
have to use @SneakyThrows, an annotation (and supply the class of the
exception(s) you want to sneakythrow as parameters), instead of using
a sneakythrows keyword.
On Sep 21, 10: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?
> 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)
> 3) Why is it that every other language ever created doesn't have
> Checked Exceptions (including Java FX)?
> 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.
> 5) Don't believe me? See what a couple people a lot smarter than me
> say:http://www.mindview.net/Etc/Discussions/CheckedExceptionshttp://www.artima.com/intv/handcuffs.html
>
> On Sep 21, 2:05 pm, Cédric Beust ♔ <[email protected]> wrote:
>
>
>
> > Yup, interesting post.
>
> > I agree with Stephen on most points except the checked exceptions part (I
> > posted this as a comment on his blog but JRoller sucks rocks so my comment
> > disappeared. Why is anyone still using this prehistoric software?).
>
> > Calling checked exceptions a "failed experiment" is a bit naive, and using
> > Spring as an illustration of this is pretty ironic. If anything, Spring
> > showed that using 100% runtime exceptions is as bad as using 0%.
>
> > I use Spring on a daily basis and I spend an enormous amount of time going
> > through pages and pages of logs containing endless stack traces of runtime
> > exceptions, all more useless than the next. I contend that if it was
> > possible to use checked exceptions judiciously, most of these errors could
> > have been caught at compile time.
>
> > Besides, in my experience, Spring has as many haters as supporters, so it's
> > not really a shiny endorsement for runtime exceptions.
>
> > It's clear that checked exceptions are hard to get right, but I am convinced
> > that they are vital to produce robust software and that the correct approach
> > is a mix of runtime and checked exceptions.
>
> > --
> > Cédric
>
> > On Tue, Sep 21, 2010 at 12:52 PM, [email protected] <
>
> > [email protected]> wrote:
> > > Interesting:
> > >http://www.jroller.com/scolebourne/entry/the_next_big_jvm_language1
>
> > > He makes some good points, although I would also advocate
>
> > > 1) building more literals into The Next Big JVM Language such as
> > > literal collections [], regular expressions /REGEXGOES HERE/, etc
> > > (basically what groovy/ruby have)
> > > 2) optional dynamic typing
>
> > > --
> > > 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]<javaposse%2bunsubscr...@googlegroups
> > > .com>
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/javaposse?hl=en.
>
> > --
> > 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.
