MOO-cows Mailing List Archive


[ Re: bf wrappers and error handling]

------- Start of forwarded message -------
From: Pieter-Bas IJdens <>
Subject: Re: bf wrappers and error handling
To: (Andrew Bakun)
Date: Tue, 11 Mar 1997 07:56:39 PST
In-Reply-To: <> from "Andrew Bakun" at Mar 11, 97 09:59:00 am
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk
Resent-From: clue-cows <>
Errors-To: clue-cows <>

>Because if you don't write your code NOW to use error catching, then when a
>server version is released in which the d flag doesn't exist or doesn't work
>like it does now, your code will break.
>Every verb in your entire database should be +d and should be using the
>error handling statements.  Leaving some verbs +d and some -d means that 
>how errors are treated are not consistant, and when I write code which is
>trying to catch an error and a error is returned instead, I need to 
>handle both cases, both getting the error as the return value and catching
>it if raised.

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

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

Home | Subject Index | Thread Index