> NB: For what it's worth, I suggested an elegant workaround for these
> issues for project coin: allow a method to declare sneakyThrows in
> addition to throws. The *ONLY* difference between throws and
> sneakyThrows is that sneakyThrows is *NOT* part of the method
> signature. e.g. if you sneakyThrow UnsupportedEncodingException, then
> if your method body throws that exception, it'll bubble up as usual
> (will not get wrapped into a RuntimeException), but, callers do not
> need to handle it.
I find it kind of ironic that in this very thread there is a code
snippet that would break with this change, the offending line being
"throw (IOException) e; // only possibility left". The other problem
with that idea is that you can have code such as
try {
a(); // sneakyThrows E
b(); // throws E
} catch(E e) {
// handle b() failing with E
}
There is a reason you are forced to wrap the checked exception, it's
that callers make the assumption no checked exception is thrown unless
it is part of the method signature.
Having had the same idea at one point though, I'm not all for pooping
on it.. ;)
With kind regards
Ben
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
