[Sorry I'm not replying in the same thread - this thread was started before I was on the list.]
> that is a discussion which started in this jira issue: > https://issues.apache.org/jira/browse/OPENNLP-99 > Steven proposed to use Iterators instead of a stream like interface. Actually, I'm proposing to support Iterators *in addition* to whatever else you do. Basically I'm suggesting that if you have a Collection-like object that people might want to iterate over, you should provide the standard Java interface to such objects: an Iterator. > java.util.Iterators do not allows us to implement the error > handling with checked exceptions nicely. Yes, with Iterators, you have to throw runtime exceptions. http://stackoverflow.com/questions/2205773/what-to-do-of-exceptions-when-implementing-java-lang-iterator http://stackoverflow.com/questions/2346978/how-should-iterator-implementation-deal-with-checked-exceptions I worry less about using runtime exceptions because I've seen *way* too much code where checked exceptions are "handled" either by auto-inserting an empty catch block (I cringe every time I see this) or catching the exception and re-wrapping it in another type of exception to match the declared "throws" type. In general, I see these two things *a lot* more often than I see code that's actually *handling* the exception. I do think it's important that users who want to catch your exceptions and handle them know what they are. But that's why you declare a custom exception type (subclassing RuntimeException), declare your method as "throws MyCusomException", and document the exception. These are all good practices regardless of whether you're using checked or unchecked exceptions. > And there are more good reasons why our ObjectStream isn't bad at all, > it can easily implemented and used in a thread safe way, which is harder > for an iterator like interface... I guess the worry is that you'd have two Iterators running over the same EventStream at the same time? Here's the code I posted in the tracker: public abstract class ObjectStream<T> implements Iterator<T> { public abstract T read(); ... private T next = this.read(); public boolean hasNext() { return this.next != null } public T next() { T result = this.next; this.next = this.read(); return result; } } So if you assume that read() is atomic, then I'm not really sure what the problem is. Two iterators would just alternate in pulling off objects from the stream, right? That's what would happen if you were using two references to the same ObjectStream as well, right? > In the end I simply think that Iterators are good if you do not have to > deal with errors and underlying OS resources, and streams are the > java way when you sadly have to take all this into account. So for those users that don't have any useful way of handling a failure at the OS level and want a simple standard Java interface, they could use the Iterator methods. For those users who do have a useful way of handling OS failures, they could either use the Iterator interface and catch the runtime exceptions, or they could use the ObjectStream interface and catch the compile time exceptions. Whichever better matches their control flow. 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. Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus
