On 1/28/11 11:06 AM, Steven Bethard wrote:
Again, I'm not asking for Iterators*instead of* whatever custom
protocol you want to design. I'm asking for them*in addition to* your
protocol.
Lets think this one trough for a minute.
We define a new RuntimeException, maybe named
IORuntimeException.
And an interface which implements java.util.Iterator:
// All methods will throw IORuntimeException when
// I/O errors occur.
interface CloseableIterator extends java.util.Iterator {
void close();
}
We could define a util method which adapts
an ObjectStream to such a CloseableIterator.
// The created Iterator also implements Iterable
ObjectStreamUtils.toIterator(ObjectStream)
Now you would like to iterate with some kind
of for each over samples or events in a file on
your hard disk.
You would need to write code like this:
--------
InputStream in = new FileInputStream("your-file.train);
Iterable it = ObjectStreamUtils.toIterator(new PlainTextByLineStream(in,
"UTF-8");
// No more explicit exception handling from here
for (String line : it) {
...
}
it.close();
--------
How do you want to get around the exception handling
the java IO interface forces you to do ?
Would you bother to close the stream ? Or do you do not
want to do this also ?
In the end you somehow have to handle the IOExceptions, thats
just how the Java API is made.
If you decide that you do not want to take care for proper IOException
handling or people tend to abuse it, then we cannot really improve
the situation with unchecked exceptions much either.
The whole OpenNLP API is almost exception handling free, but when
we load something from InputStreams the caller has to take care to
handle the IOExceptions in a professional manner. That is a responsibility
the Java API transfers to use, and we simply transfer it to the one who
is actually responsible to do something.
Jörn
