Re: [Boost-users] serialization gives memory leaks due to throwing constructors

From: David Abrahams (dave_at_[hidden])
Date: 2007-03-04 10:26:24

Andrew Mellinger <amelling_at_[hidden]> writes:

>> This throwing c++ constructor stuff is btw the way to transport errors
>> according to a lot of c++ gurus. But my persnonal opinion is that it sucks.
>> Every created object must be guarded with exception safety. 

I don't know what "guarded with exception safety" means.  You
certainly don't need try/catch blocks everywhere.

>> For large applications, this exception mecahnism is very tricky and
>> sources for a lot unwanted application terminations or memory
>> leaks.

Writing exception-safe code is not really any harder than writing code
that's correct in the presence of errors with any other
error-reporting mechanism.  In fact, given a clear understanding of
how to use exceptions effectively, they are less tricky to use
correctly than other approaches to error handling, because they
provide a high-level abstraction that lets you concentrate on what
matters.

>   I agree.  At my workplace we have a convention.  For heavyweight objects
> that would do interesting things in their constructors we instead use the
> alloc-init paradigm of Objective-C.   In this model, the constructor does
> simply non-error things, then a corresponding init (or even suite of init
> methods) does the interesting things.  This has the added benefit that the
> init method can be overridden in subclasses, and you don't need to
> re-implement all the behaviors.

The alloc-init paradigm _really_ sucks.  Instead of considering
exceptions in your constructors you end up having to guard all the
rest of the code with "what if this object failed its initialization?"
checks/handlers.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com