Re: CORRECTION Re: confused by exception handling in VC 2008
On Tue, 16 Dec 2008 23:35:56 +0700, "Alan Carre" <alan@twilightgames.com>
wrote:
"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:0vefk413mj2d6vvbimrl1lrqphsv6js5qs@4ax.com...
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?
1. Optimizer not preparing for object unwinding in sequences where an
exception (SEH or otherwise) is not anticipated ('s' or 'c' switch
extensions).
2. C++ "catch" blocks not being entered due to optimizations that do not
prepare for C++ exceptions (such as "throw obj;") where *only* extern C
functions are within visible scope.
And so on. Basically when mixing two exception types the optimizer may or
may not prepare code for either synchronous OR ansynchronous exceptions (or
both). This was all discussed long ago.
None of that is unique to using native SEH. If you want normal C++ stack
unwinding in the presence of asynchronous exceptions, you must use /EHa,
and that applies equally to _set_se_translator and native SEH. I'm not sure
what the extern "C" angle has to do with anything, because if you use /EHsc
and extern "C" functions throw C++ exceptions, you've lied to the compiler,
and you get what you deserve. Given that /EHc works only with /EHsc, it's
incompatible with asynchronous exceptions anyway.
Presumably the underlying issues remain, so I don't really buy the
portability argument. It seems to me you can #define __try/__except away
I'm not selling it.
I think it would be much more difficult to #define away __try/__except than
to simply not ever write it down in the first place. Much better to use only
C++ exception handling keywords. You're not allowed to mix the two in the
same function as far as I know, so you'd have to make C wrappers wherever
you wanted to use __try/__except that is *if* you intended to use either C++
exception handling or C++ objects, which may or may not work / unwind if an
SEH happens to come along.
If you use /EHa, you will get the unwinding when using __try/__except as
well as try/catch and _set_se_translator. You must use /EHa when using the
latter, so if you want to do the same sort of things with native SEH, it's
fair to impose the same requirement on it.
just as easily as try/catch. However, it's certain the former is more
Why would you want to get rid of C++ exception handling?
I don't. You seem to think there are profound differences WRT "robustness"
between using _set_se_translator vs. native SEH, and I'm trying to
understand what you think those differences are. The "convenience" factor I
talked about last time (quoted just below) is not a "profound difference";
it's just syntax.
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).
What's so complicated? It's like a 3 line function (as described by explicit
example in the MSDN).
In robust programs, an SE filter can be quite complicated, because robust
programs pick and choose which SEs to deal with.
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.
Because it allows you to not have to mix two exception mechanisms in the
same sources, which confuses the optimizer. That means program flow is much
more easily anticipated. Using a translator basically mashalls asyncronous
exceptions along with C++ exceptions which clearly means more robustness.
That's just not true. No matter how you dress them up, they're still
asynchronous SEs that occur outside the normal flow of control. It is the
use of /EHa that keeps the optimizer in check in the presence of
asynchronous exceptions. Using _set_se_translator alone is not sufficient,
and mixing __try/__except with try/catch isn't a factor in "confusing the
optimizer" in any way I'm aware of.
Aside: You made a glaring logical error in deducing that I was saying SEH
implies robustness when I stated only that "no SEH" or "SEH+translator" is
more robust than direct use of SEH in C++ code: A->B and A->C that does not
mean B->C (which was your deduction from translator->rubust and
translator->SEH to SEH->robust).
I explained what I meant a couple of messages ago concerning your statement
that drew a distinction between what I consider two essentially equivalent
things. I expanded on it in my last message, after you posted a whole lot
of new text and implied it was what you said originally. (That was the
reason for the "Hehe" quoted above.) If it makes you feel better to keep
harping on my "error", fine, but it doesn't advance the discussion.
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
I would want to examine the exeption where the current state of objects
created preceeding a throw was known. If I call into some math lib and I
know that sometimes I get a divide by zero, or overflow error, I'd like to
know that the current state of objects in memory is not "random" before
proceeding to handle the error.
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++
Yup, slower.
And the other things I said.
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.
No, they can't actually. Not when async exception handling is in effect.
Uh, "portable" programs don't have to worry about "async exception
handling", because the concept doesn't exist in Standard C++. However, they
can use catch(...), which is a construct that does exist in Standard C++.
There are no gurantees that catch(...) will be entered or objects unwound.
Not sure what you're getting at there.
This is all made very explicit in the MSDN.
The fact you keep referring to MSDN as some sort of reliable reference is
not a good sign. For example, I lobbied for 10 years for catch(...) not to
catch untranslated SEs under /EHs, and all the while, MSDN said that under
/EHs, "exceptions can be thrown only with a throw statement". That was
patently false, given that catch(...) was capable of catching untranslated
SEs under /EHs. For more, see:
http://members.cox.net/doug_web/eh.htm#Q2
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.
Well that's fine. Everyone has their own approach. I merely noted what the
MSDN has to say on the subject, so if you have a problem with it take it up
with MSOFT not me.
You haven't quoted anything from MSDN that I've seen, so I don't know
exactly what you're referring to, and if MSDN was wrong, I wouldn't care
beyond noting, "Yep, another MSDN error." Instead, you've been expressing
your understanding of EH in VC++, and that's what I've been responding to.
--
Doug Harrison
Visual C++ MVP