Re: Allocators and exceptions

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

On Tue, 11 Sep 2007 02:19:37 -0700, Maciej Sobczak wrote:

> On 11 Wrz, 11:16, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>>>> P.S. Exceptions in constructors is a bad idea.
>>
>>> No, it's a very good idea. Otherwise you have to deal with half-baked
>>> objects, which is Even Bigger Mess (tm).
>>
>> This is what you get when the exception is propagated out of a constructor.
> 
> In this case I want the constructor to be rolled back.
> Without exceptions (and rollback) the only option for handling errors
> in initialization of (sub)components is to leave them half-baked.

> When I create a new object and there is some error on the way, I want
> to consider the object as if it never existed.

This error is likely unrecoverable, so you have to reconsider your design
which allowed such errors.

BTW, formally everything is exactly as you wished! Observe, that

   new T(-5)

creates an object of the type T_Access. This object does not come to
existence and the compiler carefully eliminates any traces of this object.
Everything is fine!

What you actually want, but didn't say it, is that T_Access would take care
of the things it points to, so its constructor (new) would. That is not
what access types in Ada can. You want abstract access types. And this is
the core of the problem. Ada does not have abstract interfaces for built-in
types, alas.

> This is what allows me to keep abstractions and invariants: either I
> have the complete object with its guaranteed invariants, or there is
> nothing. Anything in between is mess.

This is violated upon aggregation of initialized components with side
effects. I don't argue that this is good, I only state that this is the
current language design and that it would be quite challenging to alter.

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