MOO-cows Mailing List Archive
[email@example.com: Re: bf wrappers and error handling]
------- Start of forwarded message -------
From: Andrew Bakun <firstname.lastname@example.org>
Subject: Re: bf wrappers and error handling
To: email@example.com (Pieter-Bas IJdens)
Date: Tue, 11 Mar 1997 07:59:00 PST
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]
Content-Type: text/plain; charset=US-ASCII
Resent-From: clue-cows <firstname.lastname@example.org>
Errors-To: clue-cows <email@example.com>
> 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 -------
Subject Index |