[BioPerl] Re: [Bioperl-l] How to check the validity of an accession number ?

[Jason Stajich]

I have repeatedly asked for input on these modules and for someone to
really run them through the paces with all the different types of errors
one would get.  If you can think of a good way to distinguish between
a temporary server error, disconnected network, and a non-valid accession
please propose it - esp since you must be thinking about these type of
situations in the MOBY world.   A simple spec as to what you would expect
from the client lib would go a long way to making it behave as you like.

On Sat, 8 Nov 2003, Mark Wilkinson wrote:

> Well... I'm not convinced that this is the "polite" thing to do :-)
>
> We have to be much more forgiving in the MOBY world.  The fact that THIS
> service provider does not understand the ID number, does *not* mean that
> the ID number is invalid (as you are asserting by the fact that you
> throw an error).  In MOBY we would then simply pass it off to another
> service provider who claimed to know something about it, and so on,
> until in the end we just claim "nobody knew anything about it... but
> that STILL doesn't mean it is invalid!".
>
> We certainly would never "break" due to service providers ignorance, or
> we would be broken all the time :-)
>

I don't see why trapping it with an eval doesn't work anyways.

get_Seq_by_acc seems to have the implicit behavior that you know you are
asking for something valid. what should it return when the different
error states arise?  You're going to pass on to the next service provider
whether or not the error is because the acc is unknown or the provider is
down.  I would assume that the MOBY layer is providing this type of
insulation to clients using the code?

-jason


> Mark
>
>
> On Sat, 2003-11-08 at 08:08, Heikki Lehvaslaiho wrote:
> > Mark,
> >
> > Jason's cvs commit note:
> >
> > "properly throw an error when no sequences are retrieved for a query --
> > cannot distinguish between errors and non-connections though at this
> > point, but this makes t/Perl.t now properly run when network is
> > disconnected [during an ice storm]"
> >
> > 	-Heikki
> >
> > On Sat, 2003-11-08 at 12:46, Mark Wilkinson wrote:
> > > On Sat, 2003-11-08 at 03:10, Heikki Lehvaslaiho wrote:
> > >
> > > > The change is in the bioperl code. It was put in almost 11 months ago
> > > > for the 1.2 release. As the error message indicates, line 177 in
> > > > Bio::DB::WebDBSeqI now throws an error.
> > >
> > > Although I am now "getting used to it", I have to say that I found the
> > > earlier behaviour much more sensible and easier to deal with... why was
> > > this change made in this way?
> > >
> > > Mark
> > >
> > >
> > > _______________________________________________
> > > Bioperl-l mailing list
> > > Bioperl-l at portal.open-bio.org
> > > http://portal.open-bio.org/mailman/listinfo/bioperl-l
>

--
Jason Stajich
Duke University
jason at cgt.mc.duke.edu