In Java how would you write the equivalent of Iterable which could throw exceptions?

Question

In java a class can implement Iterable which lets you use the foreach() statement and the iteration syntatic sugar:

for(T t:ts) ...

However, this does not allow you to throw exceptions on the construction for an Iterator. If you were iterating off a network, file, database etc it would be nice to be able to throw exceptions. Obvious candidates are java.io.InputStream, Reader and the java.nio.Channel code, but none of this can use Generics like the Iterable interface can.

Is there a common idiom or Java API for this situation?

Clarification: This is asking if there is a pattern or alternative interface for iterating for objects off a non-memory source. As responders have said, just throwing RuntimeExceptions to get around the problem is not recommended or what I was looking for.

Edit 2: Thanks to answers so far. The consensus seems to be "you can't". So can I extend the question to "What do you do in this situation, when this situation would be useful?" Just write your own interface?

Answer 1

Unfortunately you can't. There are two problems:

• The Iterator API doesn't declare any exceptions to be thrown, so you'd have to throw RuntimeExceptions (or non-Exception throwables)
• The enhanced for loop doesn't do anything to try to release resources at the end of the loop

This is very annoying. In C#, for instance, you can really easily write code to iterate through the lines of a text file:

public static IEnumerable<string> ReadLines(string filename)
{
    using (TextReader reader = File.OpenText(filename))
    {
        string line;
        while ( (line=reader.ReadLine()) != null)
        {
            yield return line;
        }
    }
}

Use as:

foreach (string line in ReadLines("foo.txt"))

The foreach loop calls Dispose on the IEnumerator in a finally block, which translates to "check if we need to do anything in the iterator block's finally (from the using statement)". Obviously there are no checked exceptions in C#, so that side of things isn't a problem either.

A whole (useful!) idiom is pretty much unworkable in Java due to this.