[mercury-users] Exceptions and unique modes

[Fergus Henderson]

This issue has been discussed before.  Unfortunately the mailing list
search facility is broken right now (we're in the process of moving it
to a new machine, since the old one seems to be suffering from hardware
problems), so I can't give you an exact reference.

On 14-Feb-2001, Ralph Becket <rbeck at microsoft.com> wrote:
> >From Peter Ross on 14/02/2001 16:23:43
> > 
> > Currently the only unique object which can be used with exceptions is an
> > io__state, and it makes the assumption that the io__state you get back
> > when an exception is thrown is the one that existed at the time of the
> > exception.

No, it doesn't.  The io__state that you get back when an exception is
thrown will in general be different from the one that existed at the
time the exception was thrown.  If any I/O has been done when the
exception has been thrown, then the state that you get back will
include all the side effects of whatever I/O has been done.

> I think that's an oversight: I don't see why try_io has to be io__state
> specific: surely it could be generalised to any unique type.

No, it can't.  The problem is that for an arbitrary type there is no
guarantee that there is any valid value of that type around when the
exception is thrown.  For `io__state', we know that there will always
be a valid state of the world at any point in the computation.
We can't guarantee that for arbitrary types.

> > This would suggest that to be consistent with the way io__state is
> > handled,
> > we guarantee that after an exception that the state of a unique object
> > is that at the point where the exception is thrown.
> > 
> > Thoughts?
> 
> The exception mechanism should certainly not change the state of unique
> objects.

The exception mechanism itself doesn't change the state of unique objects.
But the code which is wrapped inside an exception handler could,
if we allowed it have a `di, uo' mode.

> I wonder if we could arrange things so that old pointers to unique objects
> were still valid in the operational sense that they continue to point to
> those objects;

Code which has a `di' mode is allowed to completely clobber the
storage for the `di'-moded argument.  There's no way to guarantee that
it will contain anything meaningful when such code throws an exception.
For example, the compiler may have applied compile-time garbage collection
to explicitly deallocate the old storage, and then reused it to hold
a value of a completely different type.

The best thing to do is to either (a) make a copy of the unique object
before running the code which might throw an exception
or (b) use `mdi' modes and trailing.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------