c++ catch error raised by PPL parallel_for

Question

I have written this piece of code to catch error launched by ppl

    try
    {
        parallel_for (m_row_start, m_row_end + 1, [&functionEvaluation,varModel_,this](int i)
        {
             // do things
        });
    }
    catch(const std::exception error_)
    {
        QString t(error_.what());
    }



    try
    {
        return functionEvaluation.combine(plus<double>());
    }
    catch(const std::exception error_)
    {
        QString t(error_.what());
    }

No error is caught although I have strong suspicion that it does have exception raised (a larger try{}catch(...){} it catching an std::exception, with no clear message.

I am right with my syntax for catching exception raised in ppl code?

Benj · Accepted Answer · 2012-10-02T12:44:01.677

Your syntax is correct although there's no reason you couldn't catch by reference to avoid unnecessary copying of the exception object:

 catch(const std::exception & error_)

Check that the exception thrown actually derives from std::exception.
The PPL will only allow exceptions to propagate once all the threads have completed, could you have a thread which is still running preventing you from seeing the exception?

For debugging purposes, you could add an extra catch block:

catch(...)
{
  cout << "Unknown exception" << endl;
}

Just to check if you are getting any kind of exception thrown, however I wouldn't leave this in production code because there's no way to usefully do anything with the exception.

score 0 · Answer 2 · answered Oct 02 '12 at 12:38

0

First, check what is thrown. If you mistype the catch, it will not react. Maybe it simply is the CONST marker? const-type is not the same as non-const-type, but I actually don't remember well if catches are const-volatile-sensitive.

Second, unless strong reasons arise, always catch by reference:

catch(std::exception& error)

If you do not, then an exception copying will occur: http://www.parashift.com/c++-faq/what-to-catch.html By copying I mean object-copying, not re-raising;)

answered Oct 02 '12 at 12:38

quetzalcoatl

32,194
8
68
107

thanks! whats the problem if an exception copying occurs (i understand: the exception get copied, is that right?) ?? – kiriloff Oct 02 '12 at 18:50
The exception is copied, just like any pass-by-value parameter to any function or method. Simply, the copy-constructor is called and contents of the original exception are called to the local variable. Paradoxically, usually, this is a minor problem, of almost no importance. Exception objects usually are very small, so it looks very innocent, but sometimes can give you a headache. A classic example is, for example, when a exception of stackoverflow occurs or outofmemory. In those two cases the situation is that there are **very** little resources available, and once the exception is rised – quetzalcoatl Oct 02 '12 at 20:48
it may happen that ... making a copy in the catch block causes a second overflow, or second out-of-memory, and usually your code will not be prepared for that: the new exception will be throw not inside the catch, but at the catch itself, the catch-clause will not run and the new exception will bubble up as if there were no catch. Another thing is with ill-written resource management for custom exceptions. As your software grows, you will often create your won exception classes, or use some external libraries that throw custom exceptions – quetzalcoatl Oct 02 '12 at 20:50
Sometimes you forget to, or that library forgets to provide a correct copy constructor for exceptions. Sometimes the exceptions have dynamically-allocated data inside and destructors that free the data. Default copy-ctor does byte-for-byte copying, and if such object with pointers is copied in such way, the destructor of the copy will deallocate the original data --- but in the original object the pointers still point to that deallocated data. A bit later, kaboom, when the original exception thrown is to be destroyed. And of course, there are times that simply the exception carries – quetzalcoatl Oct 02 '12 at 20:54
TONS of trace data, and you simply really don't want to copy it :) All that things are corner cases and/or are related to possible bugs. All of them, once they occur, are really hard to find. Being safe from all of that is done by simple get-by-ref, by a single '&', so why not? You may stumble upon some frameworks like MFC where the usual way is to throw and catch by pointer instead. This is exactly due to the same reasons, just they choose pointers. This worse option, as you have to actually throw a pointer-to-exception, not an exception. But, well, such libraries exist. Still,try to use &. – quetzalcoatl Oct 02 '12 at 20:58

c++ catch error raised by PPL parallel_for

2 Answers2