"Bj�rn Persson" <spam-away@nowhere.nil> wrote in message
news:4opjf.151627$dP1.509433@newsc.telia.net...
> Jeffrey R. Carter wrote:
> > 1. An intermediate object of the type is created.
> > 2. Y's bit pattern is copied into the intermediate object.
> > 3. The intermediate object is adjusted.
> > 4. X is finalized.
> > 5. The intermediate object's bit pattern is copied into X.
> > 6. X is adjusted.
> > 7. The intermediate object is finalized.
>
> Can't Maciej's concerns be applied to step 6? What to do about
> exceptions that happen while the new X is being adjusted, after the old
> X has been finalized?

Sure, but it's a bug to let Finalize or Adjust propagate an exception. If
they do, the only reasonable assumption is that the object is corrupted. The
language bends over backwards to insure that a failure of one of these
operations for an object does not corrupt any other object (or component),
which is a strong guarantee in itself.

In just plain old (no controlled types around):
   A := B;
the raising of an exception during the assignment leaves A abnormal if A is
composite. In other words, Ada says that objects that are being assigned are
corrupted by an exception.

The solution is to not allow exceptions to be raised by Adjust. Yes, that's
not completely practical, because of Storage_Error, but even there you
should handle the exception and do what you can to prevent corruption of the
object. (Claw leaves the object invalid in this case, so future operations
on it, other than recreating it, will fail.) And this also suggests that you
should try to avoid allocating memory in Adjust (not always possible, of
course).

                       Randy.