How to create a Java Iterator that throws IOException

Question

I'd like to implement an iterator that retrieves objects from disk/network.

Iterator itr = getRemoteIterator();
while(itr.hasNext()) {
    Object element = itr.next();
    System.out.print(element + " ");
}

However the problem is that hasNext() and next() methods of the Iterator object does not allow to throw IOException. Is there any other standard interface work around this issue?

Desired code is:

public interface RemoteIterator<E> {
    boolean hasNext() throws IOException;
    E next() throws IOException;
    void remove();
}

Answer 1

Unfortunately you can't do this. Declared exceptions are part of a method's signature and while you can narrow them e.g.

interface FooCallable extends Callable<T> {
T call() throws IOException; // Narrows Exception from the parent interface
} 

you can't introduce new throws clauses or widen the declared one.

Iterator is a fundamental Java interface, used by enhanced for, so even if somehow you could do what you wanted, the compiler would need to know that

for (T obj: ioExceptionThrowingIterable) { ... }

requires the checked IOException to be caught or thrown.

It's matter of opinion, but I think you should use a custom subclass of RuntimeException and document your interface carefully. Checked exceptions are avoided in modern frameworks, e.g. Spring, because of the problems associated with them.

Edit: Borrowed and adapted from user949300's answer, you could wrap the returned object in e.g.

interface RemoteObject<T> {
    T get() throws IOException
}

Then return an Iterator<RemoteObject<T>>, and force the caller to handle the IOException when unwrapping with get:

for (RemoteObject<Foo> obj: iterable) {
    try { 
       foo = obj.get()
    } catch (IOException ex) { 
    /*
     * 9 times out of 10, the lazy user just prints the stack trace 
     * or something else inappropriate
     * which is why I despise checked exceptions
     */
    }
}

In this case, there's no need to extend Iterator, it can be used directly. In fact, you can use Collection, if applicable.

Answer 2

It isn't exactly what you want, but consider:

This is happening over a network, so it may be slow. You should be probably be using a Future (or similar).

So, instead of having your RemoteIterator<E> where next() returns a E, use

RemoteIterator<Future<E>>, where it returns a Future<E>.

In the Future.get() method, you can wrap any IOException in an ExecutionException.

Not perfect, but Future.get() implies that things may be slow, plus it does throw a checked exception which will tip off other programmers what is happening, and the natural response is to call getCause(). So this avoids most of the "WTF" aspects.

Answer 3

Next() is throwing http://docs.oracle.com/javase/7/docs/api/java/util/NoSuchElementException.html, You can write a custom Exception class, catching that exception and then throw the IOException.

Answer 4

I would rather suggest that getRemoteIterator() method should ideally throw an IOException, since objects retrieval will happen inside the method.

Answer 5

Iterator is a well-know design pattern. If the SDK Iterator doesn't fit your current needs, you could make an iterator on your own.

I find a nice explanation and sample code in this site. You can take that code as reference and make your own implementation of the Iterator Interface you need.

Answer 6

The basic problem is that you want to be able to throw a checked exception through an API which is not designed to do so.

The only legitimate way to get this to work without black magic is to wrap with unchecked exceptions. The simplest is RuntimeException:

} catch (IOException e) {
   throw new RuntimeException("failed in " + fileName, e);
}

You can then catch RuntimeException in the calling code and look at the getCause() method.

If you need explicitly to be able to tell for sure, that this is your exception then consider creating FooBarDomainException extends RuntimeException and implement the constructors you need delegating to super(...,e). You can then catch FooBarException instead and handle getCause() as above.

I will advise you against using magic to do this. When magic breaks, it tends to be in very non-obvious ways which are hard to find and fix. Additionally it will be harder for others to maintain.

Answer 7

Here is my contribution and at the bottom the stack.

It's not really what you want but it's near.

public class IOIterator<E>
   implements
      Iterator<E>
{
   @Override
   public boolean hasNext()
   {
      return index < 5;
   }

   @Override
   public E next()
   {
      try
      {
         if( index++ > 3)
         {
            throw new IOException( "True fault origin" );
         }
      }
      catch( Throwable t )
      {
         NoSuchElementException nse = new NoSuchElementException( "index: " + index );
         nse.initCause( t );
         throw nse;
      }
      return null;
   }

   @Override
   public void remove()
   {
      if( index == 0 ) throw new IllegalStateException( "call next first!" );
      try
      {
         if( index == 4 )
         {
            throw new IOException( "True fault origin" );
         }
      }
      catch( Throwable t )
      {
         UnsupportedOperationException uoe = new UnsupportedOperationException( "index: " + index );
         uoe.initCause( t );
         throw uoe;
      }
   }

   private int index;



   public static void main( String[] args )
   {
      IOIterator<Socket> it = new IOIterator<>();
      while( it.hasNext())
      {
         Socket socket = it.next();

      }
   }

}

And the exception stack trace:

Exception in thread "main" java.util.NoSuchElementException: index: 5
    at hpms.study.IOIterator.next(IOIterator.java:32)
    at hpms.study.IOIterator.main(IOIterator.java:67)
Caused by: java.io.IOException: True fault origin
    at hpms.study.IOIterator.next(IOIterator.java:27)
    ... 1 more

Answer 8

I suggest making your own interface which is structurally similar to Iterator but has the added Interface constraint that you wanted.

It sounds like what you really have here is a Stream of objects. I'd go that route, with the attendant expectation that sometimes you'll get an EOFException or the like.

Answer 9

There is one more approach to this problem. The main idea is to extend NoSuchElementException:

class RemoteIOException extends NoSuchElementException {
    ...
}

The disadvantage is that NoSuchElementException extends RuntimeException.

Answer 10

checked exception is just a syntax limit

code below from lombok http://www.projectlombok.org/

you will get

Exception in thread "main" java.io.IOException at B.main(B.java:19)

public static RuntimeException sneakyThrow(Throwable t) {
    if (t == null) throw new NullPointerException("t");
    B.<RuntimeException>sneakyThrow0(t);
    return null;
}

@SuppressWarnings("unchecked")
private static <T extends Throwable> void sneakyThrow0(Throwable t) throws T {
    throw (T)t;
}

public static void main(String[] args) {
    throw sneakyThrow(new IOException());
}

Answer 11

I posted some sample code on ideone. The basic idea is to create a custom RuntimeException class IOIteratorException that only excepts an IOException as the cause. Then you can write code like this

try
{
      iterator . next ( ) ;
}
catch ( IOIteratorException cause )
{
      cause . getCause ( ) ; // the compiler knows this is an IOException so you don't need to cast it
}