The java.lang.Iterator interface has 3 methods: hasNext, next and remove. In order to implement a read-only iterator, you have to provide an implementation for 2 of those: hasNext and next.
My problem is that these methods does not declare any exceptions. So if my code inside the iteration process declares exceptions, I must enclose my iteration code inside a try/catch block.
My current policy has been to rethrow the exception enclosed in a RuntimeException. But this has issues because the checked exceptions are lost and the client code no longer can catch those exceptions explicitly.
How can I work around this limitation in the Iterator class?
Here is a sample code for clarity:
class MyIterator implements Iterator
{
@Override
public boolean hasNext()
{
try
{
return implementation.testForNext();
}
catch ( SomethingBadException e )
{
throw new RuntimeException(e);
}
}
@Override
public boolean next()
{
try
{
return implementation.getNext();
}
catch ( SomethingBadException e )
{
throw new RuntimeException(e);
}
}
...
}
I’ve implemented a lot of Iterator, sometimes on top of with-check-exception iterators (ResultSet is conceptually a record iterator, InputStream y conceptually a byte iterator) and so on. It’s very very nice and handy (you can implement pipe & filters architecture for a LOT of things).
If you prefer to declare your exceptions, then declare a new type of Iterator (ExceptionIterator, it would be like Runnable and Callable). You can use it along or your code but you can’t compose it with outside components (Java Class Library or 3d party libs).
But if you prefer to use super-standard interfaces (like iterator) to use them anywhere, then use Iterator. If you know your Exceptions will be a condition for stop your processing, or you don’t mind a lot… use them.
Runtime exceptions are not so terrible. By example. Hibernate use them to implement proxies and stuff like that. They have to except DB exceptions but can’t declare them in their implementations of List.