[phantom@baymoo.org: bf wrappers and error handling]

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

------- Start of forwarded message -------
Return-Path: nop@ccs.neu.edu
Date: Sun, 9 Mar 1997 03:41:12 PST
Subject: bf wrappers and error handling
From: "Richard Connamacher" <phantom@baymoo.org>
To: moo-cows@parc.xerox.com
X-Mailer: Cyberdog/2.0b1
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: MOO-Cows-Errors@parc.xerox.com
Precedence: bulk
Resent-From: clue-cows <nop@nop.com>
Errors-To: clue-cows <nop@nop.com>

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?

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.

Suggestions?

Phantom
------- End of forwarded message -------

• Prev: [pbijdens@students.cs.ruu.nl: Re: bf wrappers and error handling]
• Next: [pravn@mvp.com: Re: parents and locking, listening etc]
• Index: MOO-cows
• Thread: MOO-cows