[abakun@waitress.scinc.com: Re: bf wrappers and error handling]

• Date: Tue, 11 Mar 1997 10:28:48 -0600
• From:
  "Robert J. Brown" <rj@eli.wariat.org>

------- Start of forwarded message -------
Return-Path: moo-cows-errors@parc.xerox.com
From: Andrew Bakun <abakun@waitress.scinc.com>
Subject: Re: bf wrappers and error handling
To: pbijdens@students.cs.ruu.nl (Pieter-Bas IJdens)
Date: Tue, 11 Mar 1997 07:59:00 PST
Cc: moo-cows@parc.xerox.com
In-Reply-To: <199703110733.IAA00539@bernlef.cs.ruu.nl> from "Pieter-Bas IJdens" at Mar 10, 97 11:33:28 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: MOO-Cows-Errors@parc.xerox.com
Precedence: bulk

> Yesterday, when making a wrapper for set_verb_code(), I ran into exactly the
> same problem. I think it's a bad idea that you have to program the debugging
> in builtin-wrappers yourself. Actually I think those wrappers should be 
> transparent and they should automaticaly be ran with the callers debug flag,
> just like the builtins themselves do. IMHO the MOO server just should
> ignore the bf_ d flag and do this automaticaly.

If they were transparent, you couldn't even know they were working, since they
wouldn't show up in tracebacks and such anymore.
Ignoring the wrapper's d flag value would be a gross inconsistancy.
Builtin functions don't "run with a debug flag".  The bf just returns a
condition that says "this is an error state", and the virtual machine 
determines what to do from there by looking at the invoker's d flag and
the current nest of error catching statements, either returning an actual
error value, or raising the error condition and/or generating a traceback.

Keep in mind that you NEED to handle nearly every error cleanly in your bf 
wrapper.  That's what you need to do when you write it in-line in the server.
You should also not be trying to change the world with your bf wrappers. If
you are, write/modify a true bf instead.  Permission checks and input/output
massaging are all I've ever had to put in the wrappers.

> Can anyone tell me why I'm wrong here, or will this indeed be a feature of the
> next server version/patch (perhaps with a flag on $server_options for those
> people who like long, long lists of excessive code...)?

Because if you don't write your code NOW to use error catching, then when a
server version is released in which the d flag doesn't exist or doesn't work
like it does now, your code will break.
Every verb in your entire database should be +d and should be using the
error handling statements.  Leaving some verbs +d and some -d means that 
how errors are treated are not consistant, and when I write code which is
trying to catch an error and a error is returned instead, I need to 
handle both cases, both getting the error as the return value and catching
it if raised.

Andy.
------- End of forwarded message -------

• Prev: [abakun@scinc.com: [PROG] Re: parents and locking]
• Next: [abakun@waitress.scinc.com: Re: bf wrappers and error handling]
• Index: MOO-cows
• Thread: MOO-cows