4 comments

[ 3.5 ms ] story [ 24.7 ms ] thread
We do something like this where i work. However, if a null or bad thread gets handled sometimes you get something uninformative, such as sem_wait() on top but doesn't really tell us where or what happened.

Good article, though!

Something I'm not getting here... Why not run the thing in a debugger?

E.g. dbx <executable> -> intercept -a -> run

These are crashes occurring in the wild, on users machines.
Forgive my ignorance but why not wrap the fallback_algorithm() call in it's own try/catch throws a more explicit exception??

    try {
      this_might_fail();  
    } 
    catch (exception& e) {
      try {
        fallback_algorithm();  // throws ExceptionB
      }
      catch (ExceptionB& e) {
        report_crash();
      }
    }