[Biojava-l] Remove features from a sequence

[Schreiber, Mark]

> -----Original Message-----
> From: Matthew Pocock [mailto:matthew_pocock at yahoo.co.uk] 
> Sent: Wednesday, 25 June 2003 6:17 a.m.
> To: Thomas Down
> Cc: Keith James; biojava-l at biojava.org; Schreiber, Mark
> Subject: Re: [Biojava-l] Remove features from a sequence
> 
> 
> Any way we slice this, we're going to end up implementing an 
> iterator, 
> right? The code is going to be messy - doing all the change 
> notification 
> and stuff - we can't call the normal remove features method, as that 
> will barf the iterator, which leaves us with writing the notification 
> code again inside the iterator remove(). Code duplication - twice the 
> code, twice the bugs?
> 
> So, on balance, I guess we should throw NotImplementedException on 
> remove(). Unless somebody has a bright idea?



I think this is the best way to do it. You could even get the method to
throw a concurrent modification exception though that may be confusing.
We should also document it somewhere with a big "don't do this!!!"


> 
> Well, yet again, we've been reminded that all interfaces should throw 
> exceptions for all methods that can fail. Write, read out 
> loud, repeat.


Amen and Amen

- Mark




> 
> 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  -  Biojava-l at biojava.org 
> > http://biojava.org/mailman/listinfo/biojava-l
> > 
> 
> 
> -- 
> BioJava Consulting LTD - Support and training for BioJava 
> http://www.biojava.co.uk
> 
> 
=======================================================================
Attention: The information contained in this message and/or attachments
from AgResearch Limited is intended only for the persons or entities
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipients is prohibited by AgResearch
Limited. If you have received this message in error, please notify the
sender immediately.
=======================================================================