On Sunday, 12 August 2012 at 06:22:37 UTC, Marco Leise wrote:
I read both articles and while Bruce Eckel's text read a bit
like repeated "swallow exception" to "avoid reams of code" I
found the interview insightful. Both aren't entirely negative
on checked exceptions and Hejlsberg actually wants them:
[Anders Hejlsberg]: "And so, when you take all of these
issues, to me it just seems more thinking is needed before we
put some kind of checked exceptions mechanism in place for C#.
But that said, there's certainly tremendous value in knowing
what exceptions can get thrown, and having some sort of tool
that checks."
The arguments against the Java model were:
1) The programmer, annoyed by the compiler, swallows exceptions
with empty catch clauses and forgets about them.
I think _if_ the intention is to get back to it later, you can
always write "// TODO: handle the missing icon, by loading a
stock icon from the OS". On the other hand, if you just don't
want to declare the thrown exception, then this is wrong
thinking in my opinion. Usually when I am in this situation in
Java it makes me think about the error handling: Can this error
be handled gracefully? If so, right here or should it bubble
up? Where is the right level to handle it? At the end of this
process I have the positive feeling that I got the error
handling right.
2) Versioning; a change in a function may add a thrown
exception, breaking client code. Often those clients want to
ignore any exceptions (and pass them on).
Ok, accepted. The client code would have to change its "throws"
list for no perceivable benefit.
3) Declaring the thrown exception doesn't scale well when you
call into multiple subsystems that each throw different
exceptions, where you would end up declaring dozens of thrown
exceptions.
I frankly have to say that I never worked on that big projects,
that I had to declare 40 thrown exceptions. And the question
may be asked if you should just wrap the exception into another
at that point, because you obviously reached a granularity at
which the finer details of the sub system failures have become
secondary.
So does it all boil down to the potentially long and cascading
list of "throws"?
This is not a first grade language issue, I realize that. It's
just when you come across it and find yourself documenting the
thrown exceptions in DDoc where they aren't checked or
anything, it cries for a solution. The solution current
languages take seems to be "let the exceptions slip through,
more often than not you don't handle them anyway".
How can we reap all the benefits, but avoid the manual listing
of all thrown exceptions?
My experience and conclusions are very similar to yours. I would
simply add that the versioning problem simply is a change of
interface. The compiler will force you to add a throws clause to
your method signature if your code is likely to throw a new kind
of exception (unless you handle it yourself). So you very well
know you are making a breaking change, and that you risk
infuriating your customers because of this. So I find it to be a
fairly weak argument.