Re: Checked Exceptions
On 15-12-2009 06:06, Leif Roar Moldskred wrote:
Arne Vajh?j<arne@vajhoej.dk> wrote:
I don't like the idea of having throwchecked and throwunchecked. It
could become very messy with the same exception being both.
I seems quite fair to me that the type carry the information whether
it is checked or not. If necessary just create two types.
*shrugs* I just don't see checked versus unchecked exceptions as different
_types_ but rather as different uses. UncheckedWidgetException and
CheckedWidgetException have the same semantic meaning and the same
intrinsic behaviour: they're just _thrown_ differently -- and that
difference is external and not part of their behaviour.
They do something different as checked and unchecked. If they are
different then different types is the most natural.
I don't like the extends RuntimeException => unchecked either. @Checked
and @Unchecked would be much nicer. But annotations did not exist back
then. And now it is too late.
Hmm. Is it? It's too late to get checked-ness separated from the type
system, but not for @Checked and @Unchecked annotations. As long as this
property is implicitly inherited until overridden, all Sun would need
to not break existing code would be to mark Exception as @Checked and
RuntimeException as @Unchecked.
But that would not clear up things, because extending RuntimeException
or not would still have significance.
To prevent lazy programming, let us add the rule that a method also have
to declare all unchecked exceptions which are thrown _directly_ from
within that method (i.e. thrown by an explicit throw statement in the
method body.)
Does not make sense to me.
The idea was to require the same amount of immediate effort (to add a
throws declaration) when throwing an unchecked exception as when throwing
a checked exception, so that lazy programmers don't use unchecked
exceptions just because it's easier there and then.
(Plus, I'd like to see more unchecked exceptions declared in the method
headers.)
But because you only wanted directly thrown, then that information is
rather useless.
Does not make sense to me. The code could just as well be inside
the method.
Sure -- but it's one pointless level of indentation removed. Which I'll admit
isn't a big deal, but then again the code can just as well be on the _outside_
of the method too.
It is lot easier to read if the code in a method is inside the method.
Test on type is an anti-OO thing.
Sure -- but tests on type are what the current catch statements
are all about too. They're just particularly awkward and limited
tests on type.
I would call it very nicely encapsulated.
Arne