Exception Names

[Lew]

Checked exceptions are always a source of contention, though. It gets
into an older argument. Whether or not it should be checked or
unchecked is an unwinnable argument of Java.

Because it's between users of an API who (lazily) find it "annoying" to handle
the exception and the writers of an API who (responsibly) want to make sure
that clients deal with it.

The argument between the lazy and the responsible will never be won in any
discussion, but the code written by the responsible will be better than that
written by the lazy.

 

[Arne Vajhøj]

Programmer stupidity is not a good reason to make a checked exception a
runtime exception. The entire point of checked exceptions it that it
forces programmers to deal with potentially dangerous situations in some
manner; if programmers choose to deal with them idiotically, they're
just opening themselves up to a world of hurt.

If someone is eating InterruptedExceptions, he or she probably doesn't
know what that exception means. In that case, there are likely much
larger multithreading bugs in the same code.

I am not so convinced.

I would say that in the majority of cases the programmer would
know that the the thread would not be interrupted.

Not that I want InterruptedException made unchecked, but in my
experience the use of interrupt is very rare.

Arne

 

[Arne Vajhøj]

Indeed, the Iterator interface doesn't apply because it is supposed to
be an iterator over the state of an object. The read method does
change the state of a stream, which is why I/O streams are their own
library, with their own patterns. The read method is not an iterator,
it reads, it goes to I/O and comes back with a result, and one valid
result is that there is nothing there.

We know that it is not an iterator. The discussion is whether it
could be made one.

Is hasNext supposed to block? Where is there support for that in
Iterator? How would I set a timeout?

Given how java.io works and what would make sense, then I would
say block and no timeout.

But yes - this is another potential problem.

Even if we managed to hammer out how to implement Iterator over an
InputStream, now how do we implement the other flavors of read? Does
an InputStream somehow generate a Iterator<List<Byte>> to replace
InputStream.read(byte[])?

I don't think those would fall under the iterator hat.

But it is a rather hypothetical discussion. It will not happen. For
good reasons.

Arne

 

[Karl Uppiano]

Because it's between users of an API who (lazily) find it "annoying" to
handle the exception and the writers of an API who (responsibly) want to
make sure that clients deal with it.

I only find it "annoying" when the likelihood of it happening is vanishingly
low compared to the need to use the API. It is the only exception I have
ever felt that way about. I am quite happy to write "responsible" code when
it actually has a chance of executing occasionally. This is a very
appropriate situation for a runtime exception.

The argument between the lazy and the responsible will never be won in any
discussion, but the code written by the responsible will be better than
that written by the lazy.

Forcing everybody in the entire Java community to handle an exception that
is so, well -- extremely exceptional, encourages antipatterns. Why make the
language buck human nature?

 

[John W Kennedy]

Requiring exception handlers for everyday events like End Of File and
Missing Key (in an indexed file) was one of the most annoying features of
PL/1.

....which is why the latest dialects of PL/I try to mitigate it, and why
modern languages have been avoiding it at least since Ada '83. (Though
Java, oddly enough, requires it for DataInputStream.)

 

[Karl Uppiano]

I am not so convinced.

I would say that in the majority of cases the programmer would
know that the the thread would not be interrupted.

Not that I want InterruptedException made unchecked, but in my
experience the use of interrupt is very rare.

Please note that I wasn't asking for it to be made unchecked either; given
how poorly I have seen it handled in too many cases, I just think it things
would work better if it were unchecked.

 

[Lew]

I only find it "annoying" when the likelihood of it happening is
vanishingly low compared to the need to use the API. It is the only
exception I have ever felt that way about. I am quite happy to write
"responsible" code when it actually has a chance of executing
occasionally. This is a very appropriate situation for a runtime exception.


Forcing everybody in the entire Java community to handle an exception
that is so, well -- extremely exceptional, encourages antipatterns. Why
make the language buck human nature?

It may well be that there is a mistake in the particular exception of which
you speak, but that is not the "older argument" wherein "[c]hecked exceptions
are always a source of contention". It was to that larger, more general
comment that I responded.

 

[EJP]

Not true. It defines "a special null reference, which refers to no
object" (JLS s. 4.3.1).

This is clearly a definition of a reference that is not non-null.

Yep, I had it back to front. References are defined as pointers to these
objects, and a special null reference. IOW a pointer is defined as a
reference that is non-null, not the other way round. So actually the
exception is indeed misnamed, I agree.

And I agree with whoever said that Java references are more like Pascal
pointers than anything else I can think of in a hurry.

 

[Lew]

Yep, I had it back to front. References are defined as pointers to these
objects, and a special null reference. IOW a pointer is defined as a
reference that is non-null, not the other way round.

Also not true. A pointer is not defined in the JLS as a "reference that is
non-null". Rather, "pointer" is consistently used in the JLS as a synonym for
"reference".

It does define references as pointers in s. 4.3.1, but never defines pointers
at all, just uses the term.

In fact, in s. 15.13.2 the JLS makes specific reference to the possibility of
a null pointer:

 

[BrianGoetz]

When you need to wait, and must now handle the InterruptedException, what do

you do with it?

Read Chapter 12 of Java Concurrency in Practice for the answer.

 

[BrianGoetz]

Read Chapter 12 of Java Concurrency in Practice for the answer.

Hmm, that's embarassing. That should have been "Chapter 7".

 

[Lew]

Hmm, that's embarrassing.  That should have been "Chapter 7".

You're my hero. Well, one of my heroes.

Seriously, /Java Concurrency in Practice/ is superb, both as a read
and in its usefulness. It's truly one of the best-written technical
texts I've encountered, no surprise if one is familiar with your
DeveloperWorks essays, as well as one of the most necessary.

I don't think I truly began to be a good Java programmer until I read
it and /Effective Java/ by Josh Bloch. Even after decades with
various concurrent-programming environments, there's always a lot to
learn about concurrency.

 

[Alan Gutierrez]

Forcing everybody in the entire Java community to handle an exception
that is so, well -- extremely exceptional, encourages antipatterns. Why
make the language buck human nature?

It may well be that there is a mistake in the particular exception of which
you speak, but that is not the "older argument" wherein "[c]hecked exceptions
are always a source of contention".  It was to that larger, more general
comment that I responded.

Actually, you responded to a straw man that you held up in lieu of my
more general comment.

Checked exceptions are a Java anomaly that serves only to create the
most contentious debates precisely because their is so dubious and
because they litter Java code with a lot of extra, repetitive blocks.
The type information provided by checked exceptions is not very
useful, the exception classes never seem to arrive with more than a
string message.

A responsible API client programmer can intercept unchecked exceptions
anywhere along the call stack, does not need to bury the unchecked
exception in wrapper exceptions, and good documentation of an API
tells the client programmer what to handle, what to expect.

I prefer to define unchecked exceptions that have a meaningful error
code integer and a list or map of useful bits of information from the
error location that can be used as part of a message format. I don't
consider software done until all exceptions raised have an error code
and proper error message.

That said, checked exceptions are a fact of Java and the Java
community, but the older argument is not between the lazy and the
responsible. Throwing a checked exception does not make you a
responsible programmer. That's lazy thinking.

Alan Gutierrez - (e-mail address removed) - http://blogometer.com

 

[Lew]

That said, checked exceptions are a fact of Java and the Java
community, but the older argument is not between the lazy and the
responsible. Throwing a checked exception does not make you a
responsible programmer. That's lazy thinking.

You are correct that, by itself, throwing a checked exception does not make
one a responsible programmer. However, checked exceptions are in the toolbox
of the responsible programmer, and server the purpose of coercing API clients
into dealing with the exceptions.

You are also correct that a responsible client programmer can check unchecked
exceptions. The responsible API writer has to ponder whether they wish to
rely on that, or to coerce the response with a checked exception.

Making that decision thoughtfully is not lazy thinking.

 

[Karl Uppiano]

Read Chapter 12 of Java Concurrency in Practice for the answer.

It was a rhetorical question; I know what I do with it.

 

[Karl Uppiano]

It was a rhetorical question; I know what I do with it.

Sorry, I left off the ;-)

 

[Tom Anderson]

Ugh. Out of curiosity, how does a Python programmer manage
multiple "parallel" iterations?

The builtin 'map' function takes a variable number of iterable things as
parameters; it combines them into a sequence of tuples, with one element
from each iterable, before applying a function to them. It pads shorter
iterables with None (python's version of null). If the function is None,
the identity function is used.

So (>>> being the interpreter prompt):

boys = ['Guido', 'Tim', 'Fredrik']
girls = ['Patricia', 'Sara'] # sorry, don't know any pythonesses!
map(None, boys, girls)

[('Guido', 'Patricia'), ('Tim', 'Sara'), ('Fredrik', None)]

You generally don't operate directly on iterators in python, but if you
wanted to, iterators are iterable, so:
[('Guido', 'Patricia'), ('Tim', 'Sara'), ('Fredrik', None)]

For your example:
.... print "%s\t%s" % tuple(map(lambda s: s or "", (boy, girl)))
....
Guido Patricia
Tim Sara
Fredrik

There, i've had to do a little map to turn the None into an empty string.
There may be a more elegant way to do that.

Still, doesn't compare badly to ...

List<Child> boys = ...;
List<Child> girls = ...;
Iterator<Child> ib = boys.iterator();
Iterator<Child> ig = girls.iterator();
while (ib.hasNext() || ig.hasNext()) {
if (ib.hasNext())
System.out.print(ib.next());
if (ig.hasNext()) {
System.out.print("\t"); // crude, but just for example
System.out.print(ig.next());
}
System.out.println();
}

... eh? <wink>

Now, however you use it, map() instantiates the result list, which if the
argument iterators are big is a bad move. There is an iterating version of
map, called imap, in the standard itertools package. However, it differs
from map in that it stops when the first iterable runs out, which makes it
useless for this. There's also a builtin called zip, and an iterating
version called izip, which do much the same as map with a None function,
both of which stop at the end of the shortest iterator. It's a real shame
there isn't an iterating longest-iterator version.

So here's one:

def izip2(*iters):
def take(i):
if (iters == None):
return None
try:
obj = iters.next()
return obj
except StopIteration:
iters = None
return None
iters = list(iters)
n = len(iters)
end = [None] * n
while (True):
row = map(take, xrange(n))
if (iters == end): return
yield row

With which:
.... print "%s\t%s" % tuple(map(lambda s: s or "", (boy, girl)))
....
Guido Patricia
Tim Sara
Fredrik

I'm not convinced this function is all that great - my python's getting
quite rusty. Still, it's a generator expression with a nested function!

tom

 

[Tom Anderson]

Your choice. On my tests the try/catch version was between one half
and one third the speed.

Over the reading of a whole stream?

tom

 

[Tom Anderson]

Requiring exception handlers for everyday events like End Of File and
Missing Key (in an indexed file) was one of the most annoying features of
PL/1.

I much prefer getting null, -1 or whatever in those cases - in short,
anything that a normal 'while' condition can handle .

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.

What i'd really like, though, is:

for (byte b: input) {
processByte(b);
}

But sadly this is very far from being doable in java.

tom

 

[Tom Anderson]

Very relevant point.

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!

tom