[Prev][Next][Index][Thread]

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

- Date: Tue, 11 Mar 1997 10:28:48 -0600
- From:

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

Home | Subject Index | Thread Index