# [eostrom@research.att.com: Re: bf wrappers and error handling]

"Robert J. Brown" (rj@eli.wariat.org)
Tue, 18 Mar 1997 22:46:56 -0600

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

    ------- Start of forwarded message -------
    Return-Path: moo-cows-errors@parc.xerox.com
    X-Authentication-Warning: radish.research.att.com: eostrom owned process doing -bs
    X-Authentication-Warning: radish.research.att.com: Host eostrom@localhost didn't use HELO protocol
    X-Mailer: exmh version 1.6.5 12/11/95
    To: Andrew Bakun <abakun@waitress.scinc.com>
    cc: pbijdens@students.cs.ruu.nl (Pieter-Bas IJdens), moo-cows@parc.xerox.com,
            eostrom@research.att.com
    Subject: Re: bf wrappers and error handling
    In-reply-to: Your message of "Tue, 11 Mar 1997 07:59:00 PST."
                 <199703111559.JAA18808@waitress.scinc.com>
    Mime-Version: 1.0
    Content-Type: text/plain; charset=us-ascii
    Date: Tue, 18 Mar 1997 13:07:18 PST
    From: Erik Ostrom <eostrom@research.att.com>
    Sender: MOO-Cows-Errors@parc.xerox.com
    Precedence: bulk

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

    Well, yes.  The curious thing is that you _can't_ (without a lot of hassle)
    write a wrapper that, far from changing the world, behaves _exactly as the
    built-in function does_, because the definition of "handle an error cleanly"
    is different in the in-server and in-db cases.  If you write the simplest
    possible wrapper, say, for verb_code():

      1:  return verb_code(@args);

    it doesn't behave exactly as the built-in did.  Under 1.7.9, a verb that
    was !d and that called verb_code("these", "args", "aren't", "valid") could
    rely on getting E_TYPE as a result.  Under 1.8.0, if a wrapper is installed,
    that same verb may lose control of the process altogether.

    This is a silly example (why would you want to write a wrapper that didn't
    do _anything_?) but I can understand why it might make people uncomfortable.
    Given Pieter-Bas's suggestion

      "the bf_ wrappers should automatically get the d flag from their callers"

    and Andy's criticism

      "Builtin functions don't `run with a debug flag'.  The bf just returns
      a condition that says `this is an error state'."

    one solution would be to make the built-in function return that condition
    if its "wrapper" (a strange name, since the wrapper is in some sense
    _inside_ the built-in) raises an exception.  This would return the locus
    of that return-an-error-state condition to the built-in function, where
    it's always been.

    This has other problems, but I won't go into them, because in truth, I'm
    with Andy on this.  The d flag is going to go away at some point (although
    not very soon) anyway.  Meanwhile, if you're creating wrappers, you _are_
    changing the meaning of the "built-in", and you might as well face up to
    that and check up on its callers.

    To be honest, I'm pretty uncomfortable with the built-in wrapper facility
    in any case.  I don't like the fact that you can no longer rely on a
    built-in function having a certain meaning--or even taking a certain
    number of ticks.  I pretty much think if you're going to call a verb,
    it should look like you're calling a verb.  (This is also my feeling
    about most or all varieties of "verbing properties", btw, just to stir
    up that tempest again.)

    I realize that makes things inconvenient for wizards trying to change
    built-ins under a large code base.  But I think the result of the
    built-in wrapper is often to make things inconvenient in ways that
    are not obvious and may be hard to find--especially by programmers
    who are not used to having to look for them.  !d verbs make this even
    worse, since they tend to hide the real location of the bug.

    So anyway:  I'm unlikely to change the semantics of built-in function
    wrappers with regard to the d flag on the verbs that call them, primarily
    because the new exception handling facilities are much cleaner than the
    d flag, and so I think people should be moving toward them in any case.

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