MOO-cows Mailing List Archive
[firstname.lastname@example.org: Re: bf wrappers and error handling]
------- Start of forwarded message -------
From: Andrew Bakun <email@example.com>
Subject: Re: bf wrappers and error handling
To: firstname.lastname@example.org (Pieter-Bas IJdens)
Date: Tue, 11 Mar 1997 11:25:35 PST
In-Reply-To: <199703111556.QAA03233@bernlef.cs.ruu.nl> from "Pieter-Bas IJdens" at Mar 11, 97 04:56:39 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text/plain; charset=US-ASCII
> 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 -------
Subject Index |