MOO-cows Mailing List Archive


Re: bf wrappers

>I'm in the process of creating bf_read and bf_notify hackers.

Hackers? :)

>read() and notify() are tricky verbs to create bf wrappers for.  The
>wrappers must never traceback, or else Very, Very Bad Things happen.
>Hence, they are -d and never call any verbs that do not reside on #0.

Very Bad Things, but I guess that Fixable Nonetheless by using the archwiz

>read() and notify() must, in accordance with documentation and
>compatibility with existing verbs, raise E_PERM, E_INVARG, or E_NARGS if
>called certain ways.  This is impossible to do with a -d bf wrapper.
>IMHO, raise() should override the -d status of a verb.  I see no reason
>why it shouldn't, and there must be some way to raise an error from a -d
>verb, such as the case of my bf_notify verb.

I agree fully!

>I _really_ don't want to put
>error handlers around each and every single line in bf_notify out of fear
>that it may cause a traceback and the afore mentioned Very, Very Bad

You could wrap most of the code around a (gulp) try/endtry that will catch
*anything*, and if anything is catched, sort it out (using code you'd test
a thousand times before relying upon) and raise the relevant error. Even if
there was no 'error', but you want to raise something - just keep it in a
flag variable and raise it after the endtry.

Something like -

(+d verb start)
flag = 0;
  if (won't let you)
    flag = E_PERM;
  elseif (not enough args)
    flag = E_ARGS;

    "do the actual stuff";
except blah (ANY)
  "ah, so something's b0rken in the wrapper. Report and tiptoe out...";
if (flag != 0)
(verb end)

Hopefully this makes sense. I agree it's gross, as opposed to the
alternative of having raise() just override !d.

Gustavo Glusman               Founder/administrator of BioMOO
-- BioMOO: telnet 8888


Home | Subject Index | Thread Index