Checked Exceptions
in [Java Programming]
|
From: Leif Roar Moldskred on 17 Dec 2009 08:05 Arne Vajh�j <arne(a)vajhoej.dk> wrote: > > They do something different as checked and unchecked. If they are > different then different types is the most natural. I don't agree that checked and unchecked exception actually _do_ anything different: whether an exception is checked or unchecked doesn't matter when it is thrown, it doesn't matter when it is caught[1] and it doesn't matter when the exception is processed. Even the exception itself doesn't care. In fact, the only time anything _does_ care if an exception is checked or unchecked is at compile-time, which I think shows that this isn't a case of behaviour or type but of semantics. I still don't think this difference has anything to do tied with the OO type system and having it tied to it only serves to add clutter with otherwise pointless extra classes. > But that would not clear up things, because extending RuntimeException > or not would still have significance. Granted -- but that's the "sins of the fathers": extending RuntimeException has significance in today's code so for backwards compability it will have to have significance for tomorrow's Java version as well. > But because you only wanted directly thrown, then that information is > rather useless. Fairly useless, yes, but it'd still give you some idea of in which ways a method is likely to fail gracelessly. I'd have _liked_ to have _all_ unchecked exceptions declared (except the exceptions from the runtime), but I realise that would get ridiculous for the top-level methods in a large system. (Still, might have gotten people to put more thought into their exceptions hierarchies.) > It is lot easier to read if the code in a method is inside the method. Eh. I don't see why that should be the case. It's just one level of indentation and the position of a single }. Not exactly ROT-13ing. > I would call it very nicely encapsulated. How's it encapsulated? The way multiple catch statements are evaluated is just syntactic sugar to avoid having to write a chain of "elsif( ex instance of X)". There's no real abstraction added or any additional access rules being enforced, so where's the encapsulation? -- Leif Roar Moldskred
From: Eric Sosman on 17 Dec 2009 09:59 On 12/15/2009 6:10 AM, Andreas Leitgeb wrote: > Arne Vajhøj<arne(a)vajhoej.dk> wrote: >>> Then, give us some way to handle more than one type of exception in the >>> same catch statement. "catch( FooException, BarException, WeirdException ex ) { }" >> That has been proposed before. I guess it is OK. > > I don't quite get it, what would be the actual compiletime type of "ex" > in the (here empty) catch-block. It might be Throwable, or Exception, or maybe the least common superclass of FooException/BarException/WeirdException. Such a dodge might create additional complications of its own, since the only methods and fields you could use with "ex" would be those of the chosen superclass. Most (all?) of Java's own exceptions inherit everything from Throwable so an "ex" type of Throwable would be all right, but if FooException has a getOffendingFoo() method you couldn't use it until you'd done a downcast -- which, in a "combined catch," would probably need instanceof or other reflective techniques clumsier than the separate catch blocks being replaced. -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Arne Vajhøj on 17 Dec 2009 20:20 On 17-12-2009 08:05, Leif Roar Moldskred wrote: > Arne Vajh�j<arne(a)vajhoej.dk> wrote: >> They do something different as checked and unchecked. If they are >> different then different types is the most natural. > > I don't agree that checked and unchecked exception actually _do_ > anything different: whether an exception is checked or unchecked > doesn't matter when it is thrown, it doesn't matter when it is caught[1] > and it doesn't matter when the exception is processed. Even the > exception itself doesn't care. > > In fact, the only time anything _does_ care if an exception is > checked or unchecked is at compile-time, which I think shows that > this isn't a case of behaviour or type but of semantics. Generic types is a compile time thing, but very type related. > I still don't think this difference has anything to do tied with the OO > type system and having it tied to it only serves to add clutter with > otherwise pointless extra classes. OO is very much about using type to carry information. >> But because you only wanted directly thrown, then that information is >> rather useless. > > Fairly useless, yes, but it'd still give you some idea of in which ways > a method is likely to fail gracelessly. I'd have _liked_ to have _all_ > unchecked exceptions declared (except the exceptions from the runtime), > but I realise that would get ridiculous for the top-level methods in > a large system. (Still, might have gotten people to put more thought > into their exceptions hierarchies.) I would consider having maybe 25% of exceptions listed to be worse than having 0% listed, because it may gives users a false impression. >> It is lot easier to read if the code in a method is inside the method. > > Eh. I don't see why that should be the case. It's just one level of > indentation and the position of a single }. Not exactly ROT-13ing. The whole point of having a { } for a method is to have then entire method insider it. >> I would call it very nicely encapsulated. > > How's it encapsulated? The way multiple catch statements are evaluated > is just syntactic sugar to avoid having to write a chain of "elsif( ex > instance of X)". There's no real abstraction added or any additional > access rules being enforced, so where's the encapsulation? The encapsulation is exactly what you describe. Arne
From: Arne Vajhøj on 17 Dec 2009 20:21 On 17-12-2009 09:59, Eric Sosman wrote: > On 12/15/2009 6:10 AM, Andreas Leitgeb wrote: >> Arne Vajhøj<arne(a)vajhoej.dk> wrote: >>>> Then, give us some way to handle more than one type of exception in the >>>> same catch statement. "catch( FooException, BarException, >>>> WeirdException ex ) { }" >>> That has been proposed before. I guess it is OK. >> >> I don't quite get it, what would be the actual compiletime type of "ex" >> in the (here empty) catch-block. > > It might be Throwable, or Exception, or maybe the least > common superclass of FooException/BarException/WeirdException. It may be the only possible solution. > Such a dodge might create additional complications of its > own, since the only methods and fields you could use with "ex" > would be those of the chosen superclass. Most (all?) of Java's > own exceptions inherit everything from Throwable so an "ex" type > of Throwable would be all right, but if FooException has a > getOffendingFoo() method you couldn't use it until you'd done a > downcast -- which, in a "combined catch," would probably need > instanceof or other reflective techniques clumsier than the > separate catch blocks being replaced. But the construct would only be used if the exceptions were indeed to be handled identical. Otherwise the old way could and should be used. Arne
From: Eric Sosman on 17 Dec 2009 21:56 On 12/17/2009 8:21 PM, Arne Vajhøj wrote: > On 17-12-2009 09:59, Eric Sosman wrote: >> On 12/15/2009 6:10 AM, Andreas Leitgeb wrote: >>> Arne Vajhøj<arne(a)vajhoej.dk> wrote: >>>>> Then, give us some way to handle more than one type of exception in >>>>> the >>>>> same catch statement. "catch( FooException, BarException, >>>>> WeirdException ex ) { }" >>>> That has been proposed before. I guess it is OK. >>> >>> I don't quite get it, what would be the actual compiletime type of "ex" >>> in the (here empty) catch-block. >> >> It might be Throwable, or Exception, or maybe the least >> common superclass of FooException/BarException/WeirdException. > > It may be the only possible solution. > >> Such a dodge might create additional complications of its >> own, since the only methods and fields you could use with "ex" >> would be those of the chosen superclass. Most (all?) of Java's >> own exceptions inherit everything from Throwable so an "ex" type >> of Throwable would be all right, but if FooException has a >> getOffendingFoo() method you couldn't use it until you'd done a >> downcast -- which, in a "combined catch," would probably need >> instanceof or other reflective techniques clumsier than the >> separate catch blocks being replaced. > > But the construct would only be used if the exceptions were > indeed to be handled identical. Otherwise the old way could > and should be used. That's my opinion, too, but possibly not that of the O.P. (No, wait: The O.P. was Arved Standstrom, and this sub-thread was started by Leif Roar Moldskred. So for "O.P." read "LRM." -- think of it as an override.) Anyhow, LRM. showed an example that caught IOException and handled various subclasses differently (three cases in a switchy construct). The example also caught Exception and sort-of-switched three ways on four subclasses. My prejudice is that if you're going to give different treatment to different exceptions, using different catch clauses is a simple and natural approach. The only situation in which I can imagine a catch-several-classes clause being useful is if you wanted to catch some but not all subclasses of some Exception type and treat them identically -- while letting other subclasses of the same superclass escape the catch altogether. IMHO that's too rare a circumstance to justify a new language construct and new rules to support it, but YMMV. Or LRMMMV, I guess. -- Eric Sosman esosman(a)ieee-dot-org.invalid
First
|
Prev
|
Pages: 1 2 3 4 5 Prev: how to kill a java thread by force? Next: X11 based GUI toolkit for java on unix AND windows |