Reverse Complement utility, Bio::Alg, return value problem
Steve A. Chervitz
Fri, 8 Aug 1997 17:42:29 -0700 (PDT)
> > 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.
> 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.