Checked Exceptions

[Arved Sandstrom]

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.

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.

 

[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.

 

[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?

 

[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]

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.

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]

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.

 

[Arne Vajhøj]

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]

Arved Sandstrom wrote, quoted or indirectly quoted someone who said :
Nor was COBOL, but you can still make a good living as a COBOL programmer.

The least significant bit.

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."

 

[Kevin McMurtrie]

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'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.

 

[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.

 

[Andreas Leitgeb]

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]

*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.

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.

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.

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.

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]

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]

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