Reverse Complement utility, Bio::Alg, return value problem

[Georg Fuellen]

>From mail by SteveC ...
> > > So I would favor having "set" functions (any function which can 
> > > modify the object's data) return a status indicator and (possibly) being 
> > > able to generate an exception that can invalidate the object. The issue 
> > > of how to deal with exceptions is a separate issue. I don't think I have 
> > > the best solution yet.
> > 
> > What do you think about simply raising an exception (i.e., croak) if an
> > invalid operation is attempted.  If the code "cares" about errors, then it
> > can test for exceptions using eval. 
> > 
> > The advantage of this is that (1) people definitely find out when
> > something has gone wrong (whereas they may ignore method return values)
> > and (2) we could potentially return something more interesting from the
> > set_foo() methods
> > 
> > The disadvantage is that exception handling in Perl is a bit yucky and
> > thus requires more code.  Without that code, the programs might die with
> > undesirable frequency.

We've actually discussed this a few months ago, and at theat time agreed to 
use carp().  (SteveC agrees -- just talked to him on BioMOO).
I think that's the best of both worlds, and it's in the spirit of Perl:
``Always use -w. Always  use -w'' ;-)  [-w displays all the warnings 
that a Perl script causes]. Things would be even better if Perl has
a built-in option that makes carp()s lethal if the user so desires --
I think I heard about this a few weeks ago.

SteveB: I suggest you check out at the Perl conference what ppl think is 
the best way to go -re- exception handling.. 

> Yes, it would be useful to be able to return more interesting things 
> from set_foo() methods.
> 
> I like the eval-based scheme since it closer to classical exception 
> handling than having the object trap its own errors internally. The 
> problem with my internal exception method is that you have to do alot of 
> polling on the objects to determine if anything went wrong. If you forget 
> to check an object, the error goes unnoticed (unless you try to use the 
> object later). This does allow the script to avoid dying and is fine if 
> you can catch all the errors, but that is becomming increasingly 
> difficult. By croaking, you ensure the error get recognized by some one 
> regardless of how complex the system gets. This should lead to more 
> robust code.
> 
> So I have been considering switching to an eval{} based system for 
> exception handling, perhaps combining this with my object-based 
> exception mechanism. This might make it easier to take advantage of new 
> exception handling features as Perl matures.
>