On May 3, 7:38 am, "Ben Voigt" <r...@nospam.nospam> wrote:
"Carl Daniel [VC++ MVP]"
<cpdaniel_remove_this_and_nos...@mvps.org.nospam>
wrote in messagenews:eCDY18OjHHA.4936@TK2MSFTNGP03.phx.gbl...
"newbee" <c.sun...@gmail.com> wrote in message
news:1178127888.071661.251860@c35g2000hsg.googlegroups.com...
Do try-catch blocks get triggered for all kind of exceptions,
including first chance exceptions?
I have an application that is crashing. I enabled Dr. Watson logging,
but nothing was logged, so I figured it was a first-chance exception.
Will a try-catch block stop for all kinds of exceptions?
No, a try-catch will only handle C++ exceptions, unless you use "catch
(...)" which is pretty useless because you get no information, or install
an
exception translator. To catch all exceptions, with full information
about
the failing instruction, you have to use SEH (__try/__catch/__finally in
MSVC++).
I have a catch(...) block with only DebugBreak() in it.
I tried using (__try/__catch/__finally), but got a Compiler Error
C2712 - cannot use __try in functions that require object unwinding.
Is it OK to compile using the /GX- option, at least temporarily, for
debugging puposes?
First chance refers to the debugger event that's raised when an
exception
is raised within the debuggee - it allows the debugger to "stop on
throw".
Second chance is the debugger event that's raised when an exception
percolates to the top of the exception handler stack without being
handled - it allows the debugger to "stop on not handled".
There's only one exception in your program, amd the debugger gets two
chances to intervene in the handling of that exception. In the absense
of
a debugger, first-chance and second-chance have no meaning.
No, there's actually two phases to dealing with exceptions, debugger or
not.
The first stack crawl runs exception filters (__catch condition) to find
out
if there is a handler, the second phase is stack unwinding which calls
destructors and executes __catch and __finally block bodies. I'm not
sure
whether the unwinding would occur if there is no handler at all --
usually
there is a match-all handler around the entire program which causes
termination when the stack unwinds that far (and the filter expression
for
that outermost match-all handler produces the JIT debugging dialog box).
Thanks.