Checked Exceptions
Arved Sandstrom
the author can't wait to show how "in" he or she is by excoriating
checked exceptions I'll probably write a new blog "Stupid New Language
Blogs are Considered Evil." :-)
Seriously, get over it already. The supposed anguish that checked
exceptions cause - namely, that you can't easily ignore them - is
exactly the point. I myself have never noticed that this is all that
much extra work. And what I *have* noticed - time and time again - is
that an OO language that has only unchecked exceptions leads in general
to poor error handling. But that's just a real-world observation: if it
happens to conflict with theory who am I to argue with blog theoreticians?
Thank you for your attention, and good morning.
AHS
* You know Java is pretty successful when everyone seems to use it as a
starting point for this discussion, even when they criticize it
savagely. Java is like democracy - apparently full of warts but nobody
can devise anything better that keeps as many people reasonably happy.
For the purposes of these "next language" discussions I consider C# to
be a near-Java. Although personally I do prefer C#.
Andreas Leitgeb
^^^^^^^
> Although personally I do prefer C#.
Is it a bias, or just absence of anti-bias? :-)
Lew
> If I read one more blog about what a new language should have (*) where
> the author can't wait to show how "in" he or she is by excoriating
> checked exceptions I'll probably write a new blog "Stupid New Language
> Blogs are Considered Evil." :-)
>
> Seriously, get over it already. The supposed anguish that checked
> exceptions cause - namely, that you can't easily ignore them - is
> exactly the point. I myself have never noticed that this is all that
> much extra work. And what I *have* noticed - time and time again - is
> that an OO language that has only unchecked exceptions leads in general
> to poor error handling. But that's just a real-world observation: if it
> happens to conflict with theory who am I to argue with blog theoreticians?
>
> Thank you for your attention, and good morning.
Amen, brother!
People who excoriate checked exceptions don't understand how to write APIs
dictatorially or the value thereof. They are blaming the language instead of
the real "culprit", the API author. Checked exceptions are part of the method
declaration. That means that they are there not because the language designer
said so, but because the method designer said so. They must have had a
reason. Had checked exceptions not existed, they'd've not been able to
express that reason in a compiler-enforced way.
Thank goodness Java has checked exceptions available so that the API author
can choose to use them.
--
Lew
Joshua Cranmer
> Seriously, get over it already. The supposed anguish that checked
> exceptions cause - namely, that you can't easily ignore them - is
> exactly the point. I myself have never noticed that this is all that
> much extra work. And what I *have* noticed - time and time again - is
> that an OO language that has only unchecked exceptions leads in general
> to poor error handling. But that's just a real-world observation: if it
> happens to conflict with theory who am I to argue with blog theoreticians?
Quick: what does Java throw if it can't open a file for reading?
What does C++ throw?
> For the purposes of these "next language" discussions I consider C# to
> be a near-Java. Although personally I do prefer C#.
Considering that my first introduction to C# was as the language of
choice for a programming project due in a fortnight, I much prefer Java.
Especially Swing.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
Leif Roar Moldskred
>
> Seriously, get over it already. The supposed anguish that checked
> exceptions cause - namely, that you can't easily ignore them - is
> exactly the point. I myself have never noticed that this is all that
> much extra work. And what I *have* noticed - time and time again - is
> that an OO language that has only unchecked exceptions leads in general
> to poor error handling.
While checked exceptions are a good idea, Java _does_ make it unnecessarily
cumbersome to work with them. There's no clean separation between checked
and unchecked exceptions, the concept of unchecked exceptions have been
muddled up with the concept of runtime exceptions (most exceptions thrown
by the runtime should be unchecked, but that's not a fundamental
relationship), and because of the try / catch syntax it gets awkward to
write common error-handling code.
I'd like to see the "checkedness" of exceptions be separated from the
class hierarchy of Throwables and instead be declared when you throw the
exception. After all, whether or not an error should cause a checked or
unchecked exception depends more on where in the code it occurs than on
what the error is: there is no reason why an IllegalArgumentException from
input validating code should be unchecked, as the cliend code of that
_should_ know how to deal with that exception. On the other hand, if the
IllegalArgumentException occurs deep down in the business logic where it's
assumed that the data has all been validated and is clean, it makes sense
to throw it as unchecked: none of the immediate code would have any idea
what to do anyway.
"throw new FooException( "Bad thing happened" ) as unchecked" or something
in those veins.
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.)
Next, give us an implicit, method-level try block: allow us to have the
method block be followed by catch blocks and a finally block:
public void myMethod( ) throws MyException {
...
} // end myMethod( )
catch( FooException ex ) {
throw new MyException( ex );
}
finally {
System.out.println( "myMethod exited." );
}
Then, give us some way to handle more than one type of exception in the
same catch statement. "catch( FooException, BarException, WeirdException ex ) { }"
or, hell, why not re-use the switch syntax?
catch( IOException ex ) {
case FileNotFoundException: logFileNotFound( ); break;
case EOFException: logUnexpectedEof( ); break;
default: logOtherIOError( );
}
catch( Exception ex ) {
case FooException:
case BarException: logFooBarError( ); break;
case WeirdException: logWeirdError( ); break;
default: logBadThingHappened( ); throw ex as unchecked;
} // end catch( )
--
Leif Roar Moldskred
markspace
> Then, give us some way to handle more than one type of exception in the
> same catch statement. "catch( FooException, BarException, WeirdException ex ) { }"
> or, hell, why not re-use the switch syntax?
It's now likely something like this will show up in Java 7
<http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000003.html>
Eric Sosman
> [...]
> Then, give us some way to handle more than one type of exception in the
> same catch statement. "catch( FooException, BarException, WeirdException ex ) { }"
> or, hell, why not re-use the switch syntax?
> catch( IOException ex ) {
> case FileNotFoundException: logFileNotFound( ); break;
> case EOFException: logUnexpectedEof( ); break;
> default: logOtherIOError( );
> }
> catch( Exception ex ) {
> case FooException:
> case BarException: logFooBarError( ); break;
> case WeirdException: logWeirdError( ); break;
> default: logBadThingHappened( ); throw ex as unchecked;
> } // end catch( )
The value of this escapes me. It seems you're not suggesting
a new capability, but just a new syntax for an existing capability:
catch (FileNotFoundException ex) {
logFileNotFound();
} catch (EOFException ex) {
logUnexpectedEof();
} catch (IOException ex) {
logOtherIOError();
} catch (FooException ex) {
logFooBarError();
} catch (BarException ex) {
logFooBarError();
} catch (WeirdException ex) {
logWeirdError();
} catch (Exception ex) {
logBadThingHappened();
}
All you've saved is one call to logFooBarError -- or have I
missed something?
--
Eric Sosman
eso...@ieee-dot-org.invalid
Arne Vajhøj
> I'd like to see the "checkedness" of exceptions be separated from the
> class hierarchy of Throwables and instead be declared when you throw the
> exception. After all, whether or not an error should cause a checked or
> unchecked exception depends more on where in the code it occurs than on
> what the error is: there is no reason why an IllegalArgumentException from
> input validating code should be unchecked, as the cliend code of that
> _should_ know how to deal with that exception. On the other hand, if the
> IllegalArgumentException occurs deep down in the business logic where it's
> assumed that the data has all been validated and is clean, it makes sense
> to throw it as unchecked: none of the immediate code would have any idea
> what to do anyway.
>
> "throw new FooException( "Bad thing happened" ) as unchecked" or
something
> in those veins.
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.
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.
> 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.
> Next, give us an implicit, method-level try block: allow us to have the
> method block be followed by catch blocks and a finally block:
>
> public void myMethod( ) throws MyException {
> ...
> } // end myMethod( )
> catch( FooException ex ) {
> throw new MyException( ex );
> }
> finally {
> System.out.println( "myMethod exited." );
> }
Does not make sense to me. The code could just as well be inside
the method.
> 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.
> or, hell, why not re-use the switch syntax?
> catch( IOException ex ) {
> case FileNotFoundException: logFileNotFound( ); break;
> case EOFException: logUnexpectedEof( ); break;
> default: logOtherIOError( );
> }
> catch( Exception ex ) {
> case FooException:
> case BarException: logFooBarError( ); break;
> case WeirdException: logWeirdError( ); break;
> default: logBadThingHappened( ); throw ex as unchecked;
> } // end catch( )
Test on type is an anti-OO thing.
Arne
Arne Vajhøj
For GUI then C# is easier.
Arne
Arne Vajhøj
> If I read one more blog about what a new language should have (*) where
> the author can't wait to show how "in" he or she is by excoriating
> checked exceptions I'll probably write a new blog "Stupid New Language
> Blogs are Considered Evil." :-)
>
> Seriously, get over it already. The supposed anguish that checked
> exceptions cause - namely, that you can't easily ignore them - is
> exactly the point. I myself have never noticed that this is all that
> much extra work. And what I *have* noticed - time and time again - is
> that an OO language that has only unchecked exceptions leads in general
> to poor error handling. But that's just a real-world observation: if it
> happens to conflict with theory who am I to argue with blog theoreticians?
A pretty huge portion of blogs is written by mediocre persons that
think it sounds "cool" to criticize something.
There is a lot of crap out there.
Arne
Roedy Green
<dce...@hotmail.com> wrote, quoted or indirectly quoted someone who
said :
>I'll probably write a new blog "Stupid New Language
>Blogs are Considered Evil." :-)
Java is not the final language. If you don't participate in
discussions of what is successor should be like, you can't very well
complain at the flaws of its successor. It is a bit like voting.
--
Roedy Green Canadian Mind Products
http://mindprod.com
The future has already happened, it just isn�t evenly distributed.
~ William Gibson (born: 1948-03-17 age: 61)
Arne Vajhøj
> On Mon, 14 Dec 2009 10:46:31 GMT, Arved Sandstrom
> <dce...@hotmail.com> wrote, quoted or indirectly quoted someone who
> said :
>> I'll probably write a new blog "Stupid New Language
>> Blogs are Considered Evil." :-)
>
> Java is not the final language. If you don't participate in
> discussions of what is successor should be like, you can't very well
> complain at the flaws of its successor. It is a bit like voting.
The equivalent of voting is to join the JCP/ANSI/ISO/ECMA/whatever
that actually controls the languages.
Writing at a blog is the equivalent of whining over the
politicians at the local bar.
Arne
Lew
>>> I'll probably write a new blog
>>> "Stupid New Language Blogs are Considered Evil." :-)
Roedy Green wrote:
>> Java is not the final language. If you don't participate in
Nor was COBOL, but you can still make a good living as a COBOL programmer.
>> discussions of what is successor should be like, you can't very well
>> complain at the flaws of its successor. It is a bit like voting.
The least significant bit. :-)
Arne Vajhøj wrote:
> The equivalent of voting is to join the JCP/ANSI/ISO/ECMA/whatever
> that actually controls the languages.
>
> Writing at a blog is the equivalent of whining over the
> politicians at the local bar.
Anyway, Arved said "*Stupid* New Language Blogs are Considered Evil", not
"*Well-reasoned, Intelligent* Blogs ..."
To carry the analogy further, whining at the local bar, writing letters to
your Congressperson and local newspaper (can you tell I'm from the U.S., where
we get to do that sort of thing?) and blogging are things that influence
politicians (at least here in the U.S.). Some of those whiners become
politicians themselves, perhaps even President or Vice-President (as here),
even to the point of winning the Nobel Peace Prize. Similarly, intelligent
whiners with a good point that actually makes sense can influence the
development and popularity of computer languages like Java. In fact, it's
programmers who made Java popular in the first place.
As Arved cited in his post, and I shall paraphrase to more closely match the
1947 original from Sir Winston Churchill: "No one pretends that Java is
perfect or all-wise. Indeed, it has been said that Java is the worst form of
programming environment except all those other forms that have been tried from
time to time."
--
Lew
Kevin McMurtrie
critical in infrastructure code where there is work to be done for
cleanup or diagnostics reporting. Not knowing where faults may happen
could destroy data. On front-end, they become a lot less useful. A
customer/user only needs to know that something unexpectedly failed, not
that a socket was reset on a remote service call.
I'm thankful that both exist and I don't give a crap about bloggers who
say there should be only one. Flame away at them if you wish.
--
I won't see Goolge Groups replies because I must filter them as spam
bugbear
Agreed. There's normally very little proposals of "this would be better"
just lots of "this isn't good enough" for the self declared genius.
BugBear
Leif Roar Moldskred
> The value of this escapes me. It seems you're not suggesting
> a new capability, but just a new syntax for an existing capability:
>
[SNIP]
>
> All you've saved is one call to logFooBarError -- or have I
> missed something?
Not really -- as suggested it's just syntactic sugar that makes it
easier to see which exceptions are grouped together and handled in
the same way. It would be more useful if we could place statements
before and after the case statements, but I can't think of a syntax
that doesn't get messy.
This syntax isn't very nice, but just to illustrate the idea:
while( resource == null ) {
try {
resource = aquireResource( address );
}
catch( ResourceException ex )
before: {
noErrors = noErrors + 1;
log.trace( noErrors + ". error while trying to aquire resource:" + ex.getMessage( ) );
}
case MalformedAddressException: /* Fall through */
case NoSuchHostException: /* Fall through */
case AuthorisationException: {
log.info( "Failed to resolve the address " + address + ", moving on to the next, if any." );
address = getNextAddress( );
if( address == null ) {
throw new MyInitException( "No working address." );
}
break;
}
case ImportantException: {
log.warn( "NB!: ", ex );
break;
}
case CriticalException: {
throw new MyInitException( "Bad thing happened!", ex );
}
default: {
log.debug( "Other ResourceException occured: ", ex );
}
after: {
if( noErrors > MAX_ERRORS ) {
throw new MyInitException( "Too many errors." );
}
}
} // end catch
} // end while
--
Leif Roar Moldskred
Arved Sandstrom
> It all depends on the point of view. Checked exceptions are often
> critical in infrastructure code where there is work to be done for
> cleanup or diagnostics reporting. Not knowing where faults may happen
> could destroy data. On front-end, they become a lot less useful. A
> customer/user only needs to know that something unexpectedly failed, not
> that a socket was reset on a remote service call.
I agree completely. I don't myself know why the big fuss about checked
and unchecked exceptions in Java - both have their place and it's not
that tough to make a reasonable decision about what to use where.
I'm a bit sensitive about the subject at the moment, though. I'm
currently helping a client set coding standards and also assisting with
the implementation strategy for fixing up poor decisions in existing
exception handling and logging (not to mention hardcoding). And what
happens every time the topic of Java exceptions comes up, a couple of
junior keeners have to read one of the anti-checked exceptions tracts
(like the one from Eckel), and then a lot of time gets used up (I won't
say wasted, not quite) explaining that all unchecked exceptions is not a
wonderful idea.
> I'm thankful that both exist and I don't give a crap about bloggers who
> say there should be only one. Flame away at them if you wish.
Already got it out of my system. The blogger was a guy who had only just
discovered F#, and embarked on an experiment to enumerate how Java could
be improved...oddly enough practically every improvement led inexorably
to F#. Once he's over his romance with his first functional language
he'll be back to C# or Java. His jejune comments simply momentarily
irritated me.
I look at it this way too. A lot of Java critics, when seizing on this
point, make the observation that other languages don't have checked
exceptions. So this makes checked exceptions bad somehow, that only Java
has them? Could simply mean that the designers of other languages
screwed up. In fact I think they did: there are innumerable C#
programming blogs where programmers wrestle with the lack of checked
exceptions, and come up with the same bad workarounds (*) that poor Java
programmers deliberately cause.
I sometimes re-read Q&As between Eckel and Hejlsberg just to see exactly
where the C# team went south. As near as I can tell, they left checked
exceptions out of C# because crappy programmers were abusing them in
Java. That's just wonderful - now crappy programmers are faced with the
even more unpalatable situation of all unchecked exceptions. And note
that even Hejlsberg has stated that he thinks checked exceptions are a
fine idea (he just disagrees with the Java implementation)...I wonder
how many C# zealots are aware of that?
AHS
* Among some of my favourite C# programmer suggestions:
1) "let them bubble up to the point in code where you can take care of
them": completely ignores the real-world problem that higher up in the
code you typically don't know what those exceptions are that you ned to
take care of;
2) "use a global exception handler": this is fine for those exceptions
that are going to become a "System Error: talk to Help Desk" message on
an error page...not so good for *every* exception;
3) "use a static code analyzer": actually not so bad. IOW, use a
3rd-party tool to do for you in C# what the Java compiler does for Java,
and effectively acknowledge that you wish C# had checked exceptions.
Leif Roar Moldskred
>
> 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.
> 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.
It wouldn't remove the problem that all (existing) runtime exceptions are
unchecked, but it would let us make unchecked exceptions that are not
runtime exceptions.
>> 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.)
It probably wouldn't be worth the implementation effort or the added
complexity to the specification, though.
>
> 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.
> 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.
--
Leif Roar Moldskred
Andreas Leitgeb
>> 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.
>> or, hell, why not re-use the switch syntax?
>> catch( IOException ex ) {
>> case FileNotFoundException: logFileNotFound( ); break;
>> [...]
>> } // end catch( )
> Test on type is an anti-OO thing.
I'm somewhat sure, that each of these types would specify an "upper bound"
in the same way that the catch-type itself does.
PS: I agreed to your comments on the not-quoted paragraphs.
Alessio Stalla
> If I read one more blog about what a new language should have (*) where
> the author can't wait to show how "in" he or she is by excoriating
> checked exceptions I'll probably write a new blog "Stupid New Language
> Blogs are Considered Evil." :-)
>
> Seriously, get over it already. The supposed anguish that checked
> exceptions cause - namely, that you can't easily ignore them - is
> exactly the point. I myself have never noticed that this is all that
> much extra work. And what I *have* noticed - time and time again - is
> that an OO language that has only unchecked exceptions leads in general
> to poor error handling. But that's just a real-world observation: if it
> happens to conflict with theory who am I to argue with blog theoreticians?
I don't believe the problem with checked exceptions is that you can't
easily ignore them. Rather, what I don't like about them is that often
they force you to deal with exceptions too early. For example,
consider this scenario:
class A implements interface B. B declares a void doSomething();
method.
To implement B, A uses a method in a library C which can throw a
LibraryCException.
Now A cannot alter the signature of doSomething() to throw a C-
specific exception. But A cannot catch it either, because it doesn't
know how to deal with it: should it cancel the operation? Should it
retry? Should it report failure to the user, and how? etc. So what
does A do? Wrap it in a RuntimeException and rethrow it. The net
effect is that A behaves the same as if LibraryCException were
unchecked, but it includes more boilerplate code (the try-catch needed
to wrap the exception) and obfuscates the exception itself with a
layer of wrapping, making it harder to deal with it at the upper
levels, should the need arise. I see this sort of scenario happening
very often in the kinds of applications I work on (multi-layer J2EE
apps).
Cheers,
Alessio
Arne Vajhøj
> I don't believe the problem with checked exceptions is that you can't
> easily ignore them. Rather, what I don't like about them is that often
> they force you to deal with exceptions too early.
You have the option of passing them on.
> For example,
> consider this scenario:
>
> class A implements interface B. B declares a void doSomething();
> method.
> To implement B, A uses a method in a library C which can throw a
> LibraryCException.
> Now A cannot alter the signature of doSomething() to throw a C-
> specific exception. But A cannot catch it either, because it doesn't
> know how to deal with it: should it cancel the operation? Should it
> retry? Should it report failure to the user, and how? etc. So what
> does A do? Wrap it in a RuntimeException and rethrow it. The net
> effect is that A behaves the same as if LibraryCException were
> unchecked, but it includes more boilerplate code (the try-catch needed
> to wrap the exception) and obfuscates the exception itself with a
> layer of wrapping, making it harder to deal with it at the upper
> levels, should the need arise. I see this sort of scenario happening
> very often in the kinds of applications I work on (multi-layer J2EE
> apps).
That is a problem in the definition of B.
And is really no different from that you really need to pass
an int on to doSomething, but the interface method does
not have an argument.
Bad API not a problem with checked exceptions.
Arne
Arne Vajhøj
> Arne Vajhï¿œj<ar...@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
Arne Vajhøj
> Arne Vajhøj<ar...@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.
Hm. Good question.
Arne
Arne Vajhøj
> Arne Vajhøj wrote:
>> The equivalent of voting is to join the JCP/ANSI/ISO/ECMA/whatever
>> that actually controls the languages.
>>
>> Writing at a blog is the equivalent of whining over the
>> politicians at the local bar.
>
> Anyway, Arved said "*Stupid* New Language Blogs are Considered Evil",
> not "*Well-reasoned, Intelligent* Blogs ..."
>
> To carry the analogy further, whining at the local bar, writing letters
> to your Congressperson and local newspaper (can you tell I'm from the
> U.S., where we get to do that sort of thing?) and blogging are things
> that influence politicians (at least here in the U.S.). Some of those
> whiners become politicians themselves, perhaps even President or
> Vice-President (as here), even to the point of winning the Nobel Peace
> Prize. Similarly, intelligent whiners with a good point that actually
> makes sense can influence the development and popularity of computer
> languages like Java. In fact, it's programmers who made Java popular in
> the first place.
I believe that to get results an effort has to be made - instead
of whining then do something.
Both in language development and in politics.
Arne
Leif Roar Moldskred
>
> 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
Eric Sosman
> Arne Vajhøj<ar...@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
eso...@ieee-dot-org.invalid
Arne Vajhøj
> Arne Vajhï¿œj<ar...@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
Arne Vajhøj
> On 12/15/2009 6:10 AM, Andreas Leitgeb wrote:
>> Arne Vajhøj<ar...@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
Eric Sosman
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
eso...@ieee-dot-org.invalid