MOO-cows Mailing List Archive


[ Re: bf wrappers and error handling]

------- Start of forwarded message -------
From: Andrew Bakun <>
Subject: Re: bf wrappers and error handling
To: (Pieter-Bas IJdens)
Date: Tue, 11 Mar 1997 11:25:35 PST
In-Reply-To: <> from "Pieter-Bas IJdens" at Mar 11, 97 04:56:39 pm
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 <>

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

It won't suddenly break, true, but it will be incompatible with code which does
use error catching.  I'm still of the opinion that your entire db should +d
if you are using 1.8.0pX, since it's been out for over a year and I'm told
even the latest lcore is entirely +d.  The only excuse is, in my opinion,
laziness and/or actually wanting to write sloppy/unmaintainable code.

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

True, but if you overload set_verb_code with a wrapper, and the wrapper
produces a traceback, then it's not @program producing the E_PERM 
traceback.  You really shouldn't hide that fact that you actually have a
wrapper enabled, since what happens when you call the bf is now different
than what is said happens in documentation; you can not get around the fact 
that you have created a wrapper.

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

Home | Subject Index | Thread Index