Re: [boost] [Boost-users] [review][constrained_value] Review of Constrained Value Library begins today

Subject: Re: [boost] [Boost-users] [review][constrained_value] Review of Constrained Value Library begins today
From: Mika Heiskanen (mika.heiskanen_at_[hidden])
Date: 2008-12-23 23:31:22

Thomas Klimpel wrote:

 > So a manageable solution would be to handle "valid" user errors
 > before entering the parallel sections of the programm, handle
 > the few remaining "valid" exceptions (like out of memory
 > conditions) by explicit communication between the workers,
 > and don't try to recover from "logic errors" inside
 > the parallel sections. This may force me to structure
 > my (parallel) algorithms such that they have explicit
 > resource allocation phases (during which no
 > communication occurs, but exceptions are allowed), and
 > running phases (during which no exceptions are allowed,
 > but communication may occur). Does this solution makes
 > sense? Is there a better solution for this problem?

I usually try to follow the structure you described.
However, previously I had seen no serious harm in throwing
inside the running section even if I knew I had done
the same test in the first phase.

David Abrahams wrote:

 > Detecting either a broken supposed-invariant or a failed
 > precondition means there's a logic error in the program
 > and state may already be arbitrarily corrupt.

Thank you, this pretty much nails it for me. I do believe

   http://en.wikipedia.org/wiki/Precondition

is more lenient in the definition. In particular this sentence

   If a precondition is violated, the effect of the section of
   code becomes undefined and thus may or may not carry out its
   intended work.

seems to allow more for a chance of recovery. David's
"state may already be arbitrarily corrupt" would make a big
difference in conveying the seriousness of the situation.

Regards,

--> Mika Heiskanen