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

[Steve A. Chervitz]

> > 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.

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.