Re: What does a structured exception look like to C++?
rick cameron wrote:
Hi, Doug
That's a very interesting Q&A stream. Thanks for all the insight!
My code is a DLL that is used by a web server app. Each "job"
processed by the DLL runs on a separate thread, created by the
calling app. I want to make the DLL as robust as possible, so that
even if there is an access violation during the processing of a job,
that condition is caught by the DLL and just causes failure of that
job, allowing other jobs to proceed.
You describe the one application where I would use (and have used)
catch(...) to eat structured exceptions. Actually, when I've had this
situation in the past, I use _set_se_translator to convert SE's to C++
exceptions, and gatthered and logged a bunch of context information around
the SE (stack traces, etc), but from a robustness standpoint it's the same.
I did find that it made the application more robust and, while theoretically
possible, I never encountered a case where the SE indicated corruption that
actually affected all "jobs".
(Such an AV probably represents a bug in the DLL - and I will
obviously try to fix it as soon as possible - but in the meanwhile
robustness is good!)
I have done this by compiling with /EHa and putting a catch (...)
clause in the top-level API functions of the DLL. I suppose I could
have used _try & _catch instead, but for this specific use I don't
see that there's a big benefit in doing so - and the compiler doe not
allow try/catch and _try/_catch in the same function, so my code
would be more complex!
Even if I were to use _try/_catch, and never use catch(...), I think
I still need to compile with /EHa, so that the objects on the stack
are destroyed when an AV happens, no?
Yes, that's correct. If you don't compile with /EHa there's no guarantee
that C++ statck-based objects will be cleaned up.
-cd