MOO-cows Mailing List Archive


[ Re: bf wrappers and error handling]

------- Start of forwarded message -------
From: Andrew Bakun <>
Subject: Re: bf wrappers and error handling
To: (Pieter-Bas IJdens)
Date: Tue, 11 Mar 1997 07:59:00 PST
In-Reply-To: <> 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
Precedence: bulk
Resent-From: clue-cows <>
Errors-To: clue-cows <>

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

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

Home | Subject Index | Thread Index