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

From: David Abrahams (dave_at_[hidden])
Date: 2007-03-06 15:06:26

on Mon Mar 05 2007, gast128 <gast128-AT-hotmail.com> wrote:
> David Abrahams <dave <at> boost-consulting.com> writes:
>
> Hello David,
>
>> > Another item is that I think that one of the rationales is that it is 
> cleaner 
>> > to write code like:
>> >
>> > void Foo()
>> > {
>> >    try
>> >    {
>> >       //write logic
>> >    }
>> >    catch ()
>> >    {
>> >       //write exception case(s)
>> >    }
>> > }
>> 
>> Rationales, for what?  Cleaner than what?
>
> this is more or less my interpretation of chapter 14 of Stroustrup's book 'The 
> C++ programming language'.

That fact doesn't seem to answer either question.

>> ...
>> It's almost impossible to write reasonable programs when you have to
>> "consider that one of the xxx objects can 'become' corrupt."  
>> http://groups.google.com/group/comp.lang.c++.moderated/msg/659b9db50f587dab
>> ...
>> I don't know why anyone would do that.  Which employee has 'become'
>> corrupt here, and how does the above code supposedly help?  It seems
>> to just eat exceptions and mask errors, nothing more.
>
> In a way it is. One can think of let the progam just continue its
> work, but a repair action must be scheduled the next time. This can
> be defensive or make things worse depending on the problem context.

IME defensive measures almost always make things worse.  As noted in
the thread I reference above, nobody has really developed a discipline
that tells us what things to defend against, when to stop checking,
and what we can reliably do when a problem is found.  The result tends
to be programs full of "corruption checks" and bogus "recovery code"
that never gets tested or executed, making the program much harder to
debug and maintain.  In my experience, that approach vastly increases
the likelihood of bugs.

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