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