MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

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

------- 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 -------
Home | Subject Index | Thread Index