[mercury-users] Exceptions and unique modes

[Ralph Becket]

> From: Peter Schachte [mailto:schachte at cs.mu.OZ.AU]
> 
> On Thu, Feb 22, 2001 at 05:58:27AM -0800, Ralph Becket wrote:
> > Here's my suggestion; it handles scope naturally.  For now, let's just
> > consider the case of closing open files and releasing locks etc.
> [snip]
> > Now, when I enter a try block I push a `checkpoint' onto the recovery
stack.
> > (Each checkpoint is distinct from all other checkpoints.)
> >
> > If the try block succeeds then I simply pop the checkpoint and continue.
> > If the exception handler is invoked then I simply pop items from the
> > recovery stack, freeing up the various resources that have been claimed
> > (e.g. closing files and releasing locks), but not freed, between the
> > checkpoint being created and the exception being thrown.  Dead easy.
> 
> This doesn't solve the problem of getting back the latest state of a
> particular unique thingy following an exception in a computation that may
> have altered it.  This subsumes the cleanup problem, since if you can get
> back the latest state of something after an exception, you can clean it
up.
> But I don't see how to parlay a nice unwind-protect mechanism like the one
> you suggest into the ability to get back the latest state of something.  I
> think Peter's suggesting of naming unique things is a nice solution to
> this.  If you don't want to call it global variables, then think of it as
a
> map from some king of identifier to unique things hanging off the
io__state.

Later on in that e-mail I suggested that the problem of recovering unique
objects could be handled by periodically checkpointing the state of such
an object and keeping a log of all the transformations applied to it
thereafter.
Then, if you get an exception where you would otherwise lose the state of
the 
unique object, you can recreate its state from the checkpoint and the log.  
While this is somewhat heavyweight, exceptions should be exceptional hence
one 
should not expect handling them to be cheap in all situations.  Keeping the
log 
etc. should not be particularly expensive.

Ralph
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------