on Tue Dec 23 2008, "Thomas Klimpel"
Mika Heiskanen wrote:
David Abrahams wrote:
I suggest reading through my posts in
http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/800...
which give the arguments in detail.
Thank you for the link, I read the thread from start to finish. It was not clear to me at the end that any agreement was actually reached, in particular with respect to terminology.
I also read the thread from start to finish. About halfway through the thread, I suddenly could follow the arguments given by David Abrahams, and he seems to be right. But now std::logic_error suddenly seems to make no sense any longer. Is this a valid conclusion from reading that thread?
IMO std::logic_error never made much sense for C++.
Then I reviewed my past issues with using exceptions in the light of this new insight. My worst issues with exceptions occured in connection with OpenMP and MPI. Because I used exceptions as a way to report errors to the user, I wanted them to propagate upwards out of the parallel regions. But because the exceptions don't occur synchronous in all workers, this just messed up the control flow. And neither OpenMP nor MPI try to help the programmer with the task of synchronising exceptions and propagating them upwards. However, as soon as I issue exceptions only in exceptional circumstances,
"in exceptional circumstances" has a nice ring to it, but it doesn't mean very much in actuality. I suggest you phrase your criterion moree precisely so you know what you've actually discovered. My criterion is, "issue an exception when a function cannot meet its postcondition."
the whole mess becomes much more managable again. 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.
Don't try to recover from logic errors, period, unless you have some kind of "state firewall" like a process boundary that allows you to be very sure that the rest of the system is OK. In the case of MPI, I even a process boundary might not be enough.
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).
I haven't thought about this very much in the context of MPI, but I've been doing some MPI programming myself recently, and IIUC it's important for all the processes to be following roughly the same code path. So if you get an exception in one process but not the others, it could be easy to confuse your parallel programs unless you do something to account for the problem.
Sorry if I am being a nuisance. I thought I had already understood the terminology, but reading the thread you mentioned made it a fuzzy again.
Sorry for misusing this thread. But reading through the above thread took me quite some time (yet the new insight was worth it), so now I'm eager to get some answers to the questions and thoughts that this thread induced.
Well, this is a good point; the whole thing is a bit off-topic for Boost, unless we make it about how Boost.MPI might better support exception handling. -- Dave Abrahams BoostPro Computing http://www.boostpro.com