exceptions + signaling end-of-iterator: why is it bad in Java and normal in Python?

Question

I'm really confused: The standard approach in Java is to throw exceptions only in "abnormal" conditions and not to use them to signal end-of-iterator.

examples: Effective Java, item 57 ("Use exceptions only for exceptional conditions") and JavaSpecialists newsletter 162:

Flow control

We should never cause an exception that is otherwise preventable. I have seen code where instead of checking bounds, it is assumed that the data will be correct and then RuntimeExceptions are caught:

Here is an example of bad code (please don't code like this):

public class Antipattern1 {
   public static void main(String[] args) {
     try {
       int i = 0;
       while (true) {
         System.out.println(args[i++]);
       }
     } catch (ArrayIndexOutOfBoundsException e) {
       // we are done
    }
  }
}

whereas it is standard to use this idiom in Python, e.g. StopIteration:

exception StopIteration

Raised by an iterator‘s next() method to signal that there are no further values. This is derived from Exception rather than StandardError, since this is not considered an error in its normal application.

Why is it bad for Java but good for Python?

Answer 1

Python and Java have vastly different approaches to exceptions. In Python, exceptions are normal. Look up EAFP (Easier to ask for forgiveness than permission) in the Python glossary. Also check what Wikipedia has to say.

StopIteration is just an example of EAFP – just go ahead and get the next thing from the iterator, and if that fails, handle the error.

If the code is more readable with a non-local exit, in Python you use an exception. You don't write checks, you just deal with failures if things don't work out. There's absolutely nothing shameful about it, in fact it's encouraged. Unlike in Java.

---

Now for a specific case of StopIteration: Consider generator functions.

def generator():
    yield 1
    print('Side effect')
    yield 2

To support some kind of has_next() method, the generator would have to check for the next value, triggering the print before the 2 is asked for. The value (or exception raised) would have to be remembered in the iterator. If has_next was called twice, only the first one would trigger the side effect. Or the next value could always be precomputed, even if it's not needed.

I find Python's semantics – computing only whenever the next value is needed – the nicest alternative.

Of course Java doesn't have resumable generators, so it's hard to compare here. But it's some anecdotal evidence that StopIteration generalizes better than hasNext().

Answer 2

There is nothing that stops you from using exceptions like that in java, it just looks ugly, at least to a java developer.

The main reason is that stacktraces from exceptions are expensive, and possibly also that java developers might be slightly more concerned about spending computing resources than Python developers.

Java is also a rather "clean" language - some would say fundamentalistic, which is one of the reasons it's a nice language. (* see comment)

Anyway. Fundamentalists (and some normal people) thinks that using exceptions for normal flow just isn't The Right Way... :-)

But besides that, recent jvm's detects that you are generating a lot of stacktraces for the same spot of code, and will actually throw exceptions without them "after a while" to speed up things.

Answer 3

Java sometimes does it, too: "All implementations of DataInput methods use EOFException instead of return values." In this case there's no way to use the usual sentinel value, -1.

Answer 4

The reason its not recommended is because in java, exception handling is generally expensive to process and recover from. When an exception is thrown, it causes a the jvm to go backtrack what is was doing in order to provide a stack trace which is never a good thing for performance. In short, it's language misuse - there will usually be a cleaner, more efficient way of handling logic. Consider the following code:

try {

    int x = service.getValue();

    if(x > 5)
        throw new NumberTooBigException("Too Big");
    else
        throw new NumberTooSmallException("Too Small");

} catch (NumberTooBigException e) {

    System.out.println("i think it's too big...");

} catch (NumberTooSmallException e) {

    System.out.println("i think it's too small...");

}

A better approach is to use just use java's intended control logic:

if(x > 5)
    System.out.println("i think it's too big...");
else
    System.out.println("i think it's too small...");

As you can see from comparing these two snippets, exception handling is kind of ridiculous - overkill for what the sample intends to do. A better approach for the example you posted would be something like this:

String[] args = {"one", "two", "three"};
for(String arg : args)
    System.out.println(args);
}

Exceptions are better used for when things really go wrong, like IOException("no space left on device"), ClassNotFoundException("can't find your code to run") or NoRouteToHostException("Can't connect to host").

Answer 5

Exceptions in Java captures execution stack, which is extremely slow: How slow are Java exceptions?

If you use exception in a control flow pass null as Throwable. Otherwise following standard Java librery code will be called through hierarchy of super calls:

public Throwable() {
    fillInStackTrace();
}

public synchronized Throwable fillInStackTrace() {
    if (stackTrace != null ||
        backtrace != null /* Out of protocol state */ ) {
        fillInStackTrace(0);
        stackTrace = UNASSIGNED_STACK;
    }
    return this;
}

private native Throwable fillInStackTrace(int dummy);

Answer 6

StopIteration exists in Python for simple iteration over any sequence.

Using an exception to implement this was a design choice, and it really isn't that inconsistent with Java's exception mentality. An iterator's next() method being called when there are no more elements is an exceptional condition, and catching that exception behind the scenes in a for loop is a pretty simple way to implement "take items until there aren't any left".

Answer 7

There is no right or wrong answer to this. Exception handling is a neutral control flow construct, and the best use of it depends on context and style.

In this case, both Java and Python do the same thing, for the same reasons: java.util.Iterator's next() uses NoSuchElementException to signal end-of-iterator. This is simply good style, in both languages: the alternative of using a special sentinel return value is is much worse, for various reasons.

As a rule of thumb, you should consider the use of exceptions whenever you write a function that wants to signal more than one kind of control flow return. This includes abnormal error conditions, but good use of exception signalling is certainly not limited to that.