# [janus@cam.org: Re: bf wrappers and error handling]

"Robert J. Brown" (rj@eli.wariat.org)
Mon, 10 Mar 1997 16:19:37 -0600

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    ------- Start of forwarded message -------
    Return-Path: nop@ccs.neu.edu
    X-Sender: janus@198.168.100.7
    In-Reply-To: <AF48529D-8DA6D@199.174.144.42>
    Mime-Version: 1.0
    Content-Type: text/plain; charset="us-ascii"
    Date: Sun, 9 Mar 1997 12:25:30 PST
    To: moo-cows@parc.xerox.com
    From: Richard Godard <janus@cam.org>
    Subject: Re: bf wrappers and error handling
    Sender: MOO-Cows-Errors@parc.xerox.com
    Precedence: bulk
    Resent-From: clue-cows <nop@nop.com>
    Errors-To: clue-cows <nop@nop.com>

    At 6:41 -0500 09/03/97, Richard Connamacher wrote:
    >I'm writing a wrapper to notify().  For it to have the same behavior as
    >notify(), it has to be able to raise or return an error depending on
    >whether or not it's being run with the 'd' flag set.  How do I make sure my
    >wrapper has the same behavior?
    >
    >notify is a common verb to be run -d, because a traceback on it can be
    >rather nasty.  So should I simply return an error?  But then there are
    >times when it is run +d on purpose.  I need a way to raise or return an
    >error depending on its caller's debug status; perhaps a new builtin
    >function to do so?

    No need for a new builtin-function, verbs should all be +d and use the
    error handling constructs. There are not that many places where the
    notify() built-in function is used. Changed those place to catch errors.

    And make your wrapper raise errors.

    >I can always check..
    >
    >c = callers();
    >if (index(verb_info(c[4], c[2])[2], "d"))
    >  raise(result);
    >else
    >  return result;
    >endif
    >
    >But, that breaks when notify is run from an eval, and uses precious ticks
    >in a verb where you want to be using as few as possible.

    Very bad idea indeed :)

    Richard
    ------- End of forwarded message -------