Exception Names

[Tom Anderson]

Then no one would handle it.


Making 'InterruptedException' runtime would not have helped; indeed, it
would have exacerbated the problem.

For once, i think i might agree with the anti-checked-exception crowd
here.

InterruptedException is almost universally misunderstood, and almost
universally dealt with by catch-and-forget. This is exactly the wrong
thing to do with it, but people do it because they're scared to let it
pass, or do what it takes to terminate their method early. The reason they
do it is that the compiler won't let them ignore it. It screams at them
until they throw or catch,

If it was a RuntimeException, the compiler wouldn't bother them, they'd
ignore it, and they'd effectively default to letting it pass, like
declaring it as a throws would do now. And that means that all their
methods would respond to interrupts by immediately stopping and
terminating, which is probably the right behaviour in most cases (and if
they're using finally blocks right, it might even happen cleanly). Code
which cared about interruption - the code which is expecting control to
return to it after interruption - could still catch it. Problem more or
less solved.

People would have learned the hard way that they were getting the
exception, then still handled it incorrectly.

Except most of the time, they wouldn't be getting it, i reckon.
Interruption isn't something that just happens, it happens when code
farther out has interrupted the code that's running, and in that case,
rapid transfer of control to that code is exactly the right thing to do.

tom

 

[Martin Gregorie]

You mean so you can do something like:

int b;
while ((b = input.read()) != -1) {
processByte(b);
}

?

The EOFException version would be:

try {
while (true) {
int b = input.read();
processByte(b);
}
}
catch (EOFException e) {}

I do agree that the former is easier on the eye.

The PL/1 subset G version was even uglier:

dcl file_end bit(1) init('0'B);

on endfile(filename) file_end = '1'B;

do until(file_end);
read file(filename) into(file_rec);
call process_record(file_rec);
end;

....but then I remember somebody saying that PL/1 was designed by taking
the more awkward features of COBOL and Fortran, wrapping them in a block
structure and adding any additional misfeatures that seemed like a good
idea at the time. IMO it makes even COBOL look well designed.

The exception trap (the ON statement) really stands out as a misfeature
because it can be put anywhere in the program provided its outside the
block that contains its trigger and, as you can see, has no direct
connection with the control structure it affects.

 

[Lew]

I'd say that getting end of stream is a highly exceptional event for a
read method. The vast majority of the time, you get a byte back!

Nice little bit of rhetorical spin there. You define majority relative to the
number of read events, where I was referring to the number of streams.

I'm going to stand by the notion that most of the time *one uses a stream* one
reads the whole thing. Your statement that most of the reads do not hit the
end of the stream is trivially correct, but that still doesn't make reading a
stream all the way through an exceptional occurrence.

 

[Lew]

For once, i [sic] think i [sic] might agree with the anti-checked-exception crowd here.

InterruptedException is almost universally misunderstood, and almost
universally dealt with by catch-and-forget. This is exactly the wrong
thing to do with it, but people do it because they're scared to let it
pass, or do what it takes to terminate their method early. The reason
they do it is that the compiler won't let them ignore it. It screams at
them until they throw or catch,

Making it a runtime exception to suit bad programmers is a bad solution. Make
programmers learn their job; that's the right solution.

If it was a RuntimeException, the compiler wouldn't bother them, they'd
ignore it, and they'd effectively default to letting it pass, like

Which isn't really the right thing to do.

declaring it as a throws would do now. And that means that all their
methods would respond to interrupts by immediately stopping and
terminating, which is probably the right behaviour in most cases (and if

Probably not. The point is to let the thread gracefully handle being
interrupted, which is unlikely to happen with an immediate stop and termination.

they're using finally blocks right, it might even happen cleanly). Code

But now you're talking about responsible programmers, who presumably will
learn the proper care and feeding of InterruptedException and won't mind that
it's a checked exception.

which cared about interruption - the code which is expecting control to
return to it after interruption - could still catch it. Problem more or
less solved.

People would have learned the hard way that they were getting the
exception, then still handled it incorrectly.

Tom:
Except most of the time, they wouldn't be getting it, i [sic] reckon.
Interruption isn't something that just happens, it happens when code
farther out has interrupted the code that's running, and in that case,
rapid transfer of control to that code is exactly the right thing to do.

After, of course, gracefully handling whatever the interrupted thread has to
handle. For example, as Mr. Goetz recommends, it probably has to call
'Thread.currentThread().interrupt()' before moving on.

I swan the exception has to be handled, so making it checked is not so harmful.

 

[Tom Anderson]

Nice little bit of rhetorical spin there.

It's not spin, it's a different perspective.

You define majority relative to the number of read events, where I was
referring to the number of streams.

Yes, exactly.

I'm going to stand by the notion that most of the time *one uses a
stream* one reads the whole thing. Your statement that most of the
reads do not hit the end of the stream is trivially correct, but that
still doesn't make reading a stream all the way through an exceptional
occurrence.

Okay, fair enough.

I also think that whether an event is exceptional has at best a marginal
connection to whether it's a good idea to use an exception for it. I think
that's an overly literal and dogmatic approach to take.

tom

 

[Mike Schilling]

I also think that whether an event is exceptional has at best a
marginal connection to whether it's a good idea to use an exception
for it. I think that's an overly literal and dogmatic approach to
take.

The you like

int i = 0;
try
{
while (byte b = barray[i++])
{
// process b
}
}
catch (IndexOutOfBoundsException ex)
{
; // OK, we're done with the array
}

If not, why not?

 

[Arved Sandstrom]

It's not spin, it's a different perspective.


Yes, exactly.


Okay, fair enough.

I also think that whether an event is exceptional has at best a marginal
connection to whether it's a good idea to use an exception for it. I
think that's an overly literal and dogmatic approach to take.

tom

Generally I see little rhyme or reason as to why some occurrences in
Java are handled with return values and others with exceptions. For
example, there's nothing exceptional about not finding a file or trying
to write to a read-only file, and yet we've got FileNotFoundException.

IOW, exceptions in Java are typically used for _expected_ behaviour.
IMHO rather than discussing what exceptions to add, we ought to be
discussing how many exceptions that aren't exceptions we can get rid of.
An exception should be for a situation that causes a break away from
normal program flow...and handling end of stream doesn't fit that bill.

In case I wasn't clear -)), I'm arguing for _more_ methods with return
values, not less.

AHS

 

[Mike Schilling]

I also think that whether an event is exceptional has at best a
marginal connection to whether it's a good idea to use an
exception
for it. I think that's an overly literal and dogmatic approach to
take.

The you like

int i = 0;
try
{
while (byte b = barray[i++])

Syntax error? The intent is clear, though.

Yeah, I switched from for loop to while loop partway through but
didn't finish the job. Still, you see what I meant, and I'm sure
everyone else does too.

 

[Wojtek]

Arved Sandstrom wrote :

Generally I see little rhyme or reason as to why some occurrences in Java are
handled with return values and others with exceptions. For example, there's
nothing exceptional about not finding a file or trying to write to a
read-only file, and yet we've got FileNotFoundException.

IOW, exceptions in Java are typically used for _expected_ behaviour. IMHO
rather than discussing what exceptions to add, we ought to be discussing how
many exceptions that aren't exceptions we can get rid of. An exception should
be for a situation that causes a break away from normal program flow...and
handling end of stream doesn't fit that bill.

In case I wasn't clear -)), I'm arguing for _more_ methods with return
values, not less.

I would rather use an exception than a return value for some things.
Like a file that cannot be found.

Otherwise I might need to pass a value back through many methods, back
to where my application can handle the problem.

Setting up a try/catch high up, then calling a method, which calls a
method, ..., which tries to open the file. If there is a problem I do
not need to make a test at each method to see if I can continue
processing, or I need to return right away. It can become VERY
cumbersome passing back a false (or whatever).

And there may be other problems that appear also. Maybe the file open
is OK, but the disk is almost full. Maybe the stupid user pulled out
the USB drive, and so on.

Using an exception I can handle the problem at a point in the
application which was designed to recover gracefully.

 

[Stefan Ram]

We also have File#exists() and File#canWrite(). This is not so

When testing such properties before using them, there always
is the slight chance that the properties might have changed in
the meantime.

Therefore, the operation to use the property must have a means
to signal a failure. But this means does not have to be an
exception, it also can be any other possible path of
information transfer to a caller, like the value of the call
expression.

Now, often they say that exceptions should be used for
»exceptional situations«, but this might be a tautology. It
does not actually explain, what constitutes an »exceptional
situation«.

I just had the idea of another approach: The notation of calls
of Methods in programming was derived from the notation of
functions in mathematics¹:

y = sin x (1)

. This means »y is the sine of x.«. It makes sense even as a
natural-language sentence: The order of the words in (1) is
the same order as in the English-language sentence.«

Therefore, one can consider a program with

y = sin x

as very readable.

write( value, file ); (2)

also can be nearly-parsed as natural language: »Write the
value to the file.«

But when both value-methods and action-methods are mixed
we get:

status = write( value, file ); (3)

. Now there is no natural-language English sentence anymore
that makes sense, correctly describes what is intended by the
above statement, and preserves the order of words (structure)
of the above statement (3). Also, such usage is not known in
mathematics.

With exceptions, one can continue to use the more »natural«
forms of function/procedure call as in (1) and (2).:

try
{ write( value, file ); }
catch( final java.example.cantWriteToFileException e )
{ ... }

Now, this, again, /can/ be nearly-read as a natural-language
sentence: »Try to write to value to the file, but if your
attempt should fail, then ....«, the order of words is
preserved.

So a guide-line to use exceptions might then be:

»Use exceptions, when this makes your source code more
readable. Especially, to give the call site a more
natural-language-like structure.«

¹: The Java Code Convention to always use verbs for method
names are not followed by Sun Microsystems, Inc. itself:

»Methods should be verbs«

http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367

»static double sin(double a)«

http://download.java.net/jdk7/docs/api/java/lang/Math.html#sin(double)

The correct guideline is given by Rob Pike:

»Procedure names should reflect what they do;
function names should reflect what they return.«

http://www.lysator.liu.se/c/pikestyle.html

For function names, this corresponds with the proven practice
of mathematics. For both function names and procedure names,
it corresponds with the structure of natural languages (at
least, of English, the lingua-france of programmers). So it
will make programs more readable.

 

[Arved Sandstrom]

Arved Sandstrom wrote :

[ SNIP ]

I would rather use an exception than a return value for some things.
Like a file that cannot be found.

Otherwise I might need to pass a value back through many methods, back
to where my application can handle the problem.

Setting up a try/catch high up, then calling a method, which calls a
method, ..., which tries to open the file. If there is a problem I do
not need to make a test at each method to see if I can continue
processing, or I need to return right away. It can become VERY
cumbersome passing back a false (or whatever).

And there may be other problems that appear also. Maybe the file open is
OK, but the disk is almost full. Maybe the stupid user pulled out the
USB drive, and so on.

Using an exception I can handle the problem at a point in the
application which was designed to recover gracefully.

In Java it's a moot point anyway for opening files, because usually it's
a call to a stream constructor that does the deed. So there's no option
for a return value anyway.

I suspect one's views on exceptions versus return values will vary
widely depending on the kinds of apps one deals with. For example, for
some years now my bread and butter has been J2EE applications. While
J2EE apps are replete with exceptions, IMHO using them doesn't really
make error handling easier than it would be with return values. I'm not
saying that exceptions make things worse, just not appreciably better.

AHS

 

[John W Kennedy]

In Java it's a moot point anyway for opening files, because usually it's
a call to a stream constructor that does the deed. So there's no option
for a return value anyway.

The lack of a back-channel in constructors was the specific reason that
Bjarne Stroustrup decided that exceptions had to be added to C++.

 

[Mike Schilling]

The lack of a back-channel in constructors was the specific reason
that Bjarne Stroustrup decided that exceptions had to be added to
C++.

Can you enlarge on that? It almost makes sense to me, but remains
elusive.

 

[Stefan Ram]

The lack of a back-channel in constructors was the specific reason that
Bjarne Stroustrup decided that exceptions had to be added to C++.

I also have this recollection, but was not able to find a
source for it. If someone knows a source, I would be happy to
read about it.

An alternative means to exceptions would be multiple return
values:

( status, object )= new classname( arguments );

Or the return of 0 in:

new classname( arguments )

similar to malloc.

Both would usually not permit nesting to be correct, as in:

new classname0( new classname1( arguments ))

(One does not want to evaluate »new classname0( ... )«,
if »new classname1( arguments )« did not work.)

But if the result includes a status value, then
»new classname0« might behave in such a manner that

new classname0(( ERRORSTATUS, referencevalue ))

gives

( ERRORSTATUS, undefinedvalue )

I.e., the error status is just passed through. (Extending
this idea, however, one possible re-invents exceptions.)

 

[R. Clayton]

Can you enlarge on that? It almost makes sense to me, but remains
elusive.

There's a number of ways status can be returned to the caller, including by a
return value (or part of the return value), by a reference prameter, or by a
global variable (a la errno in *nix). Constructors don't have return values.
Overloaded unary or binary operators (in c++) can't have extra parameters (and
probably can't use return values). Global variables are universally applicable
but not thread safe without expensive coordination. That leaves exceptions,
although you shouldn't forget error functions (or closures if you have them) to
be called when something untoward happens.

 

[John W Kennedy]

I also have this recollection, but was not able to find a
source for it. If someone knows a source, I would be happy to
read about it.

I'm pretty sure it's in Stroustrup's own C++ book.

 

[John W Kennedy]

On the other hand, exceptions are syntaxically bulky. Mosty, to catch an
exception, you have to open a try block, and variables declared in that
block are not accessible to the catch clause. Moreover, exceptions were
designed to move the exception-handling code out of the way, so that the
main code was more readable. If the exception occurs often (once for
each processed stream), then the catch clause is reached under normal
conditions; so moving the corresponding code out of the way might have
adverse effects on readability.

One may also observe that exceptions are rather expensive to build
(since they capture the current stack trace) so it seems that the
designers of Java used the idea that exceptions did not occur often and
thus could afford to be expensive.

So it is quite understandable that some people, even some who do not
like the -1, are not fond of exception handling either.

All this was argued out long ago, in the design of Ada '83. At the time,
exceptions were one of several language features in ill repute due to
design errors in the PL/I version. Java seems to have followed the same
line of thought as Ada.

 

[Lew]

There's a number of ways status can be returned to the caller, including by a
return value (or part of the return value), by a reference prameter, or by a
global variable (a la errno in *nix). Constructors don't have return values.
Overloaded unary or binary operators (in c++) can't have extra parameters (and

And don't exist in Java anyway.

probably can't use return values). Global variables are universally applicable

And don't exist in Java anyway, although static variables fill that void.

but not thread safe without expensive coordination. That leaves exceptions,
although you shouldn't forget error functions (or closures if you have them)

Yecch, closures.

 

[Arved Sandstrom]

Lew wrote:
[ SNIP ]

Yecch, closures.

My feelings precisely. Regardless of the actual merits of closures, my
feeling is that if they get added to Java 7, we'll see use of them akin
to what happened with generics - 90% plus of developers won't understand
how to use them properly. Of that group most will _not_ use them, which
is likely a good thing. Some will, which is not. Of the much smaller
group that do understand how to use them, some will actually use them
(and properly), but inevitably their codebases will land into the hands
of those who don't understand closures, leading back into problems.

AHS