Re: Allocators and exceptions

["Randy Brukardt" <randy@rrsoftware.com>]

"Simon Wright" <simon.j.wright@mac.com> wrote in message
news:m2ir6fobaz.fsf@mac.com...
> Maciej Sobczak <see.my.homepage@gmail.com> writes:
>
> > What should the constructor do *after* handling the exception?
> > Leave the object half-baked?
>
> I'm not sure exactly what Stephe meant by 'propagate'. It certainly
> seems a bad idea to allow a Constraint_Error to propagate
> unhandled. But what would be wrong with dealing with the problem and
> then raising an appropriate exception from the constructor? (even
> Constraint_Error if gnat makes sense).

Because Ada *requires* storage leakage in such cases (although some
compilers ignore the language definition and finalize anyway). An allocated
object cannot be finalized until it's *type* is finalized or until an
Unchecked_Deallocation is called -- and an Unchecked_Deallocation is not
going to be called if a constructor propagates an exception. So the
(inaccessible) object is supposed to hang around for a long, long time.

The "proper" way to handle this is to ensure that default initialize of an
object never propagates an exception, and then wrap the allocator properly:

    type Access_T is access all T;
    procedure Free is new Unchecked_Deallocation (T, Access_T);
    function Alloc_Object (...) return Access_T is
       A_T : Access_T := new T; -- Default initialized.
    begin
       A_T.all := <constructor>;
       return A_T;
    exception
        when others => Free(A_T); return null;
    end Alloc_Object;

But I'm not going to argue that this is an ugly and complex way of handling
this.

                    Randy.