MOO-cows Mailing List Archive
[firstname.lastname@example.org: Re: bf wrappers and error handling]
------- Start of forwarded message -------
From: Pieter-Bas IJdens <email@example.com>
Subject: Re: bf wrappers and error handling
To: firstname.lastname@example.org (Andrew Bakun)
Date: Tue, 11 Mar 1997 07:56:39 PST
In-Reply-To: <199703111559.JAA18808@waitress.scinc.com> from "Andrew Bakun" at Mar 11, 97 09:59:00 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text/plain; charset=US-ASCII
Resent-From: clue-cows <email@example.com>
Errors-To: clue-cows <firstname.lastname@example.org>
>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 -------
Subject Index |