Re: Abnormal objects - how they can become normal again?

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Hi,
> 
> If an object is abnormal, it can become normal again after a successful
> completion of an assignment to this object.
> The problem is that during the assignment, the finalization of the
> (still abnormal) object should take place. How it can happen, if at the
> same time evaluation of the abnormal object is erroneous?
> 
>  From the programmers perspective, there are two cases:
> - "simple" types (like Integer), with basically empty finalizers;
> nothing bad can happen there, so assignment to an uninitialized variable
> is harmless,
> - controlled types; but there, finalizers come bundled with initializers
> so that there's no way to make an object abnormal by just forgetting to
> initialize it - the only way to make an object abnormal would be to
> abort a previous assignment, which is a no-no anyway.
> 
> I understand the issue from the implementation point of view, but the
> wording in AARM (13.9.1) seems to be a bit fragile. From the
> language-lawyer's point of view: how to assign to an abnormal object, if
> its evaluation is erroneous?
> Is the object evaluated before it's assigned to or as part of the
> assignment process (especially finalization)?

If the abnormal object is not controlled, then you can just do a whole
object assignment to repair it; there's no read of the object in that
case.

Controlled objects require special care.

Abnormal objects can be caused by aborts, and by exceptions.

In the case of aborts, you can take advantage of the fact that certain
operations are abort deferred (finalization, for example -- look up
"abort deferred" in the RM index for a complete list).  In the case of
exceptions, you can write code that doesn't raise exceptions.  Note that
11.6 says that the exceptions can appear to move around.  For example:

    X := Y;
    Z := W;

If "Z := W;" raises Constraint_Error, then this can cause X to become
abnormal!

One case I know of that can't be dealt with properly (while relying only
on portable rules in the RM) is Storage_Error.  It's like abort, in that
it can happen pretty much anywhere, but unlike abort, there's no way to
prevent S_E from happening in a certain region of code.

Another way to deal with abnormal (possibly controlled) objects is to
add a level of indirection.  I believe you can Unchecked_Deallocate an
abnormal object (not sure).  Assignment of access values does not
involve finalization.  So when you have a possibly-abnormal object, you
could simply throw it away and create a new one.

- Bob