I must say that I started this discussion with an open mind, but the more I think about it, the more I am convinced that Bruce Eckel is right: Java doesn't need checked exceptions, they are a failed experiment.
One could extend the concept and say the same about strong typing.
But then one could extend the concept to unit testing as well.
I think that in an open development environment the need for quality assurance given by local semantic controllers (compilers, unit testers) is much reduced.
At the same time, continuous integration *is* a requirement and this needs some sort of programmatic semantic evaluability (and here is where strong typing gets useful to indicate failed dependencies).
My point is: contract solidity empowers SoC but slows innovation. It's a price to pay and I think there is no way out.
I think checked exceptions are not harmful *IF* and only if, they indicate a strong and useful contract that can be used by local semantic controllers in a meaningful way.
if not, well, yes, they are harmful, just like
Object get(Object) throws Exception
is stupid because gives a false sense of solidity.
I do NOT think that
InputStream open(File) throws IOException
is harmful, rather the opposite. It clearly indicates things that *could* happen normally in the execution of the program and give you a way to react to that.
Leo is right: exceptions in java are signals more than errors. They are, in fact, exceptions to the rule, but not something that doesn't belong to the rule at all (those are Errors!).
Ugo, I totally agree with you that Cocoon is a mess regarding exceptions and I would welcome any attempt to remove useless wrapping and stuff like that.
My opinion is that if you are given an exception that you don't know what to do with, that exception should not have been checked.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
