Re: CORRECTION Re: confused by exception handling in VC 2008
On Tue, 16 Dec 2008 08:37:59 +0700, "Alan Carre" <alan@twilightgames.com>
wrote:
*Avoid SEH* or *use translator*, the two options we've been discussing.
Since we've been discussing SEH throughout this thread, the issue of using a
translator to convert asynchronous SEH exceptions into synchronous C++
exceptions naturally did come up. Specifically where one wants to receive
SEH info, and do everything humanly possible to reduce the probability of
encountering the kinds of hazards that typically arise as a result of mixing
the two exception-handling mechanisms. So, following the MSDN documentation
(which discourages use of SEH altogether) I simply reiterated that if you're
going to combine SEH and C++ exception handling, you should at least do it
right. And the the safest way to mix the two is to set up a translator and
then let everything flow through the regular C++ exception handling
mechanism.
What do you think the "hazards" are?
I characterized this approach as a way of "silencing" asynchronous
exceptions such that all exception handling (outside of the translator of
course) is in line with the pure C++ model. And, as a side-benefit, the
whole thing can easily be #defined away should one wish to target another
platform. In other words, it's the most robust way to use SEH in a C++
environment, with portability a mere #define away.
Presumably the underlying issues remain, so I don't really buy the
portability argument. It seems to me you can #define __try/__except away
just as easily as try/catch. However, it's certain the former is more
powerful (supports resumption), while the latter is more convenient (allows
defining objects with dtors in the same function as try/catch; can use C++
types in catch instead of writing complicated filter expressions for
__except).
How the above (basically word-for-word MSDN recommendations) could be
construed as an argument that "SEH implies robustness" is certainly beyond
me.
Hehe. What you *originally* said was, "you won't require the robustness
that you can achieve by either avoiding SEH altogether or using a
translator". IOW, "You can achieve robustness by either (A) or (B)". I
guess I'm not clear how "using a translator" gains you "robustness" that
you would sacrifice if you were to use native SEH.
Ya, so I think it's not as simple as just terminating on any Win32
exception. Division by zero, or integer overflow and so on are not critical
enough, in my opinion, to abort execution. On more serious errors I think
one would advise the user that the program requires a restart and offer a
chance to save their work *to a different filename* before doing so (perhaps
with some mention of "no gurantees"). Certainly that'd be an improvement
over a register dump/stack trace. I mean, they can always say "no".
OK, so you are talking about using SEH to recover from bugs, which, by
definition, place the program in an unknown state. In order to use SEH via
_set_se_translator, you must use /EHa everywhere the SE you want to
translate can be thrown, everywhere you catch the translated SE, and if you
want object destruction during stack unwinding, along all control paths
that can cause the exception. Since you are interested in bug recovery and
aren't targeting specific anticipated issues that can occur in correct
programs, it would seem you need to cast a wide net. This means using /EHa
throughout the program, which will increase its size, make it slower, and
subject catch(...) to catching all SEs you don't translate into C++
exceptions in addition to the ones you do translate. I don't think putting
flagrant bugs into catch(...) is a good idea, and I would not advise using
it at the same time as /EHa. This is another reason I don't buy the
"portability" argument, as portable programs certainly can use catch(...)
safely.
I think if a last-ditch provision to save data is the goal, it might make
more sense to use __try/__except at the top of the program. You would
continue to use /EHs, which if I'm not mistaken, means stack unwinding WRT
local object destruction won't have occurred in the __except clause, which
is arguably a good thing, on the basis that the less code executed
following a crash, the better. Could you do the same with
_set_se_translator and try/catch? I guess you could compile just the
main.cpp file with /EHa, but I suspect it would still be possible to catch
translated SEs in catch(...) in the rest of the program that uses /EHs.
I think this is all *very* complex and subtle, and it requires a great deal
of thought and planning to use /EHa successfully on a wide scale. I've only
used SEH in cut-and-dried ways, over small areas of code, e.g. (1) I used
native SEH to commit reserved memory and resume execution following an
anticipated access violation, and (2) I used _set_se_translator to
translate delay-load failure SEs into C++ exceptions for graceful error
reporting. I didn't use /EHa for the former, and I used it for the latter
on just the file that required it.
--
Doug Harrison
Visual C++ MVP