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

[Steve A. Chervitz]

> > 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.
> 
>   Yes, I remember discussing this and recall the agreement.
> 
>   However, SteveC's comments have re-opened the issue for me.  The reason
> is that while the carp()'s are visible to the user, there is no way for
> the program to do anything about them.  That is, if something illegal
> happens, the user (if they're sitting at the console) will get a warning,
> but the program can't take any corrective action.

Good point.

>   Maybe the old return value idea (suggested by SteveC), combined with
> carps and croaks (depending upon severity) is the best approach.  This, of
> course, means that one can't do the sort of repeated operations which
> would be desirable and which are possible if the self object is returned.

Returning an object would still be possible if the code which expects 
this behavior is properly wrapped in an eval block.  When I consider what 
I've been doing, I'm closer to emulating croak than carp for most of the 
exception handling I do. In effect, I'm doing an object-specific croak:
an object is disabled and the script doesn't crash. The object can then 
be querried about why it is disabled and how it became so. The problem is 
that there is no way to enforce that an object gets querried. Croaking 
would force the issue.

So I am now more in favor of croak. I think it would encourage the 
creation of more fault-tolerant code and it would help maintenance since 
potential trouble spots would be flagged by an eval block.

SteveC