Re: Allocators and exceptions

[Stephen Leake <stephen_leake@stephe-leake.org>]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> On 12 Wrz, 14:29, Stephen Leake <stephen_le...@stephe-leake.org>
> wrote:
>
>> The rule should be:
>>
>>     Constructors should not propagate exceptions up; they must handle
>>     all exceptions internally.
>
> No.
> What should the constructor do *after* handling the exception?
> Leave the object half-baked?
> Do you want to introduce additional states to the object design just
> to handle the "oops I'm not initialized" case?
>
> The only reasonable solution is probably to use custom factories
> instead of built-in allocators.
>
> But... can we prohibit the user from using the allocator for the given
> type?

Hmm. You seem to be equating "allocator" with "constructor"; I was
not.

I thought you meant "custom factory" when you said "constructor".

Hmm. Maybe you mean only Finalization.Initialize by "constructor";
that is called by "new".

In any case, I'll modify my statement;

    Constructors (ie Initialize or user-built factory functions) must
    handle all exceptions internally. If in some situation the object
    cannot be properly constructed, any memory allocated should be
    deallocated, all other appropriate cleanups done, and then a final
    "Failed" exception should be raised to indicate the failure to the
    caller.

The point is that the caller of the constructor either gets a properly
initialized object, or a single well-defined exception indicating that
the object could not be created. In the latter case, all proper
cleanup is already done by the time the final exception is raised.

I think that is consistent with what you want to have happen.

If the constructor is designed to return an access value, an
alternative to raising the final exception is to return null, but an
exception is probably better.

-- 
-- Stephe