MOO-cows Mailing List Archive
Re: bf wrappers
>I'm in the process of creating bf_read and bf_notify 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)
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 bioinformatics.weizmann.ac.il 8888
- bf wrappers
- From: Richard Connamacher <firstname.lastname@example.org>
Subject Index |