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

From: gast128 (gast128_at_[hidden])
Date: 2007-03-07 05:00:04

David Abrahams <dave <at> boost-consulting.com> writes:

> >> 
> >> 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.

Maybe I may quote mr Stroustrup in his book: "The exception handling mechanism 
provides an alternative to the traditional techniques when they are 
insufficient, inelegant and error prone. It provides a way of explicitly 
separating error handling code from 'ordinary' code, thus making the program 
more readable and more emenable to tools" (etc.)

I ran across a nice mail thread which a lots of pro's and cons about this 
matter:
http://www.dbforums.com/archive/index.php/t-689599.html

> 
> >> ...
> >> 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.

I have quite the opposite opinion: I work on a new version of a large 
application and the old team had a very strict exception policy which gave the 
application instability and crashes. Because of this experience we built a 
much more forgiveness (without sacrifycing data integrity) in the application, 
which makes it more robust. This does of course not mean that every pointer is 
checked, but an example can be that subsystems must check their arguments 
before continuing their work. Incorrect arguments will not be signaled by 
exceptions.

wkr,
me

I should one day give my real name..