Far from being an issue of sloppiness, the absence of checked exceptions
presents a very real limitation to the design of well-encapsulated
components. Documentation is important, of course; nobody's questioning
that. However, if documentation were enough, then return- and parameter-
checking would be extraneous as well. You will probably argue that
exceptions are different because they are more closely related to the
implementation. However, that's the crux of the problem: interfaces are
supposed to prevent implementation details from being exposed.
exactly, so interfaces should not have any information about the
implementation details. No offence, but if an interface defines 'Throws
FileIOException' it clearly defines that the implementation can/should
access files, however that's probably not the case. So it tells the caller
FALSE information. This is something different than an implementation of
the interface defines that it throws FileIOException, since it then is
legitimate to say 'I throw exception xyz', because we're talking about a
given implementation then.
But just as you're not limited to returning the exact type specified in
a method signature, you aren't being crippled by checked exceptions.
Make no mistake about it. As long as any inner exception is a subclass
of or wrapped in an instance of the throwable types that are permitted
by the interface, nothing prevents you from passing back any extended
data specific to the implementation at hand.
True, but for exceptions I'd like to make an erm.. exception
If
the returntype is a given baseclass, code calling the method can work with
the base class, otherwise they wouldn't have called the method. However,
an exception thrown should TELL what is wrong, not being a flag that says
'Hi, something was wrong, look inside my tree of inner exceptions to see
what's wrong', because you can't catch inner exceptions. Exceptions thrown
therefore have to match exactly what went wrong. Encapsulation of
exceptions in higher order exception classes is therefore making
exceptions a moot technology.
In fact, checked exceptions offer a safer way to throw your own
exceptions, because you'll know that doing so won't break the calling
code if it's not expecting your particular exception's runtime type.
That's what it all boils down to: by replacing the underlying
implementation without making any guarantees on the type of data to
expect, you aren't running the risk of an unexpected exception bubbling
up clear off the stack or of needing to rewrite code everywhere, as is
currently the case with .NET.
Of course you do run the risk! If a new implementation implements
the interface differently and has to encapsulate a new exception into a
higher order exception to avoid breakage of the exception definition in
the interface, you're creating poopcode.
I see exceptions as: if the DIRECT caller can recover from a given
set of exceptions, catch these and recover there, and bubble up the rest,
because these are fatal for that position in the call stack and perhaps a
higher level in the callstack can recover from these. New exceptions in a
new implementation of an interface can be handled then as such, they end
up as being 'fatal' and will report an error message or abort a
transaction or whatever. Eric Gunnerson has enlisted these situations
before, in the mile long thread about the same topic
Finally, if you're still not convinced, remember that you'd be free to
automagically add "throws Exception" to all your methods and resume your
work hassle-free. =)
Yeah right. If that is necessary 'checked exceptions' is useless.
If a given rule enforces you to do something but can be overcome by
cheating (like throws Exception) the 'enforcement' is not mandatory
anymore so callers of code defining exceptions can't rely on the list they
see and therefore you can also just say 'no' to checked exceptions and
save you all the trouble.
FB