Re: Allocators and exceptions

[Simon Wright <simon.j.wright@mac.com>]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "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).
                       that
>
> 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;

I guess I had misunderstood what's meant by 'constructor', becasue
this is just what I had in mind ... and there are far worse things to
leak than memory, such as locks, file handles, data structure
integrity etc, and those we can handle even in a constructor (ie
function returning a value of the type rather than a pointer to a new
value of the type).