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

"Robert J. Brown" (rj@eli.wariat.org)
Sun, 16 Mar 1997 11:05:13 -0600

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    ------- Start of forwarded message -------
    Return-Path: nop@ccs.neu.edu
    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 11:25:35 PST
    Cc: moo-cows@parc.xerox.com
    In-Reply-To: <199703111556.QAA03233@bernlef.cs.ruu.nl> from "Pieter-Bas IJdens" at Mar 11, 97 04:56:39 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
    Resent-From: clue-cows <nop@nop.com>
    Errors-To: clue-cows <nop@nop.com>

    > Maybe you are right here, but my only point was that the bf_ wrappers should
    > automaticaly get the d fag from their callers, so that it doesn't matter if
    > you are using a wrapper or not, basicaly just like the builtins already do.
    > This way it doesn't matter if you are using a wrapper or not, and the code
    > that relies on running -d will not suddenly break when you use a wrapper.

    <rant>
    It won't suddenly break, true, but it will be incompatible with code which does
    use error catching.  I'm still of the opinion that your entire db should +d
    if you are using 1.8.0pX, since it's been out for over a year and I'm told
    even the latest lcore is entirely +d.  The only excuse is, in my opinion,
    laziness and/or actually wanting to write sloppy/unmaintainable code.
    </rant>

    > Take the old @program code for example, if you wrap set_verb_code and make it
    > +d it will suddenly give a traceback for E_PERM. That's quite inconsistent
    > realy, -d code giving tracebacks. (Making it -d has other disadvantages).

    True, but if you overload set_verb_code with a wrapper, and the wrapper
    produces a traceback, then it's not @program producing the E_PERM
    traceback.  You really shouldn't hide that fact that you actually have a
    wrapper enabled, since what happens when you call the bf is now different
    than what is said happens in documentation; you can not get around the fact
    that you have created a wrapper.

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