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

• Date: Mon, 10 Mar 1997 16:19:37 -0600
• From:
  "Robert J. Brown" <rj@eli.wariat.org>

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

• Prev: [janus@cam.org: [SERVER] [BUG] Waiting for network I/O?]
• Next: [jcampbell@itol.com: 1.8.0p6]
• Index: MOO-cows
• Thread: MOO-cows