So, on balance, I guess we should throw NotImplementedException on remove(). Unless somebody has a bright idea?
Well, yet again, we've been reminded that all interfaces should throw exceptions for all methods that can fail. Write, read out loud, repeat.
Matthew
Thomas Down wrote:
Once upon a time, Keith James wrote:
It may also be worth noting that you /can/ do this:
while (seqI.hasNext()) { Sequence seq = seqI.nextSequence();
for (Iterator i = seq.features(); i.hasNext();) { i.next(); i.remove(); } }
which is a way to avoid ConcurrentModificationException, but also a way to avoid informing any listeners to Sequence that all its Features have been stripped - and is likely to be bad.
Ugh, that's actually pretty nasty, to the extent that I would call it a bug. My initial thought was to fix it by firing the appropriate events, but this doesn't work since the Iterator.remove() method can't throw a ChangeVetoException. So the options are:
- Hack it (throw something like IllegalStateException)
- Add ChangeVetoRuntimeException (seems like a Bad Thing to
me since we've always said that change vetoes are checked
exceptions up until now.
- Forbid Iterator.remove(). Easiest to code, but seems like a shame.
None of these options seems terribly appetizing to me, but I think we should do something.
Any preferences?
Thomas.
_______________________________________________
Biojava-l mailing list - [EMAIL PROTECTED]
http://biojava.org/mailman/listinfo/biojava-l
-- BioJava Consulting LTD - Support and training for BioJava http://www.biojava.co.uk
_______________________________________________ Biojava-l mailing list - [EMAIL PROTECTED] http://biojava.org/mailman/listinfo/biojava-l
