[MUD-Dev] Re: atomic functions
J C Lawrence
claw at under.engr.sgi.com
Wed May 13 11:09:02 New Zealand Standard Time 1998
On Thu, 7 May 1998 14:32:35 +0200 (MET DST)
Felix A Croes<felix at xs1.simplex.nl> wrote:
> J C Lawrence <claw at under.engr.sgi.com> wrote:
>> My language construction uses exceptions heavily. In fact an
>> exception is the default (only) return path. An exception encludes
>> specifics on where it was raised, and may be bound with other
>> code-supplied data sets. An ERR_OKAY exception is thus the normal
>> return with any return code being accessably by querying the
>> exception for its bound data set, and with ERR_<anything_else>
>> being the error cases (with possible bound data sets).
> Complications arise if you want to pass along arbitrary data with
> the error, and arrays are shared in your system (as they are in
> mine). The data could then include information which also exists in
> a state where no changes have occurred. My solution is not to allow
> the passing along of data in this case, apart from the information
> contained in the errorcode itself.
While I don't have exactly this problem, the problem exists in general
with any exception mechanism as the ancillary passed data may move out
of context as the exception unrolls the stack (eg ancillary data is a
stack member). My approach is to force implicit copies for all
exception data. No originals are returned.
Yes, you can work about this by returning references (pointers), but
I'm not attempting to to prevent planned suicide, merely the more
obvious forms of accidental death.
J C Lawrence Internet: claw at null.net
(Contractor) Internet: coder at ibm.net
---------(*) Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
MUD-Dev: Advancing an unrealised future.
More information about the MUD-Dev