Re: Controlled types and exception safety

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 30 Nov 2005 14:57:07 +0100, Maciej Sobczak wrote:

> Let's say that I want to write a stack in Ada. Making it a Controlled 
> type seems to be a good idea, so that we have hooks for initialization, 
> adjusting and finalization. Let's say that I have two stack objects, X 
> and Y:
> 
> X, Y : Stack;
> 
> These objects were populated with some data, so that each of them 
> manages its own internal dynamic data structure.
> Now, I do this:
> 
> X := Y;
> 
> and the following happens (this is what I understand, please correct me 
> if I'm wrong):
> 
> 1. X is finalized. This allows me to clean up (free) its internal data.
> 2. Y is *shallow-copied* to X, so that in effect X and Y share their state.
> 3. X is adjusted. This allows me to duplicate its internal structure so 
> that it becomes independent from Y.
> 
> later:
> 4. Both X and Y are finalized. This allows me to clean up (free) their 
> resources.
> 
> For everything to work correctly it's important that two separate stack 
> objects *never* share their internal dynamic data structure, otherwise 
> bad things can happen. It would be also fine not to leak memory.
> 
> Now, the interesting part: let's say that during adjustment (3.) some 
> error happened (like low memory condition or whatever) that resulted in 
> raising an exception

ARM 7.6.1 reads: "It is a bounded error for a call on Finalize or Adjust to
propagate an exception.
[...]
For an Adjust invoked as part of an assignment operation, any other
adjustments due to be performed are performed, and then Program_Error is
raised."

> I think that the inherent problem comes from the fact that the 
> finalization of X was forced *before* its adjustment.
> The canonical C++ way is to *first* make a copy of new value (because 
> this is when errors might occur, so that even if they occur, there was 
> no change in the destination object) and *then* inject the duplicate 
> into the destination object, getting rid of its old state (and this is 
> assumed to be nothrow).

Here the semantics of "copy", "inject", "duplicate" is ill-defined. In
general, you can copy a set of bits, but you cannot an object without
defining it in the terms copy-constructor. In Ada's case copy-constructor
is defined as Bitwise copy + Adjust. It is an atomic operation. Which is
equivalently means that in general case you cannot define any reasonable
semantics for its partial completion.

> The "Ada way" looks like selling the house *before* looking for the new one.
> 
> What do you do to avoid surprises?

Don't let exceptions propagate.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de