try-catch won't catch in the Release mode

[lauch2]

In a default MFC - dialog based application (VC6.0 or VC7.1), the following
try-catch code does not be catched in Release mode, but it is OK for Debug
mode. Any compiler/link option is required to turn on or turn off?

try
{
int *i = 0;
*i = 0;
}
catch(...)
{
MessageBox("Catched");
}

Thanks in advance,
lauch

[William DePalo [MVP VC++ ]]

"lauch2" <la****@discussions.microsoft.com> wrote in message
news:C3**********************************@microsof t.com...

In a default MFC - dialog based application (VC6.0 or VC7.1), the
following
try-catch code does not be catched in Release mode, but it is OK for Debug
mode. Any compiler/link option is required to turn on or turn off?

try
{
int *i = 0;
*i = 0;
}
catch(...)
{
MessageBox("Catched");
}

Thanks in advance,

The problem is that you are confusing structured exceptions and C++ typed
exceptions.

C++ typed exceptions use try and catch.

Win32 structured exceptions, of which division by zero is one, use __try and
__except.

What is happening is that the optimizing sees no possible way that a C++
exception can be thrown in your snippet and so it simply removes it (or
optimizes it away or elides it).

If you link with compile with the /EHa option you inform the compiler that
exceptions can come out of nowhere. The try, catch machinery will not be
removed. And due to what many consider a defect in the compiler, the
structured divide by zero exception will get caught in your catch-all
handler.

If you really need to do this, and I my estimation it is necessary in
development and often unwise otherwise, you should use _set_se_translator()
to translate a structured exception to a typed exception.

By the way, VS2005 does not confuse typed and structured exceptions.

Regards,
Will

[lauch2]

thanks William,

What is happening is that the optimizing sees no possible way that a C++
exception can be thrown in your snippet and so it simply removes it (or
optimizes it away or elides it).
Do you mean that it just needs to remove the complier option /O2 in a
default setting for the release build?

thanks
lauch,

"William DePalo [MVP VC++ ]" wrote:
"lauch2" <la****@discussions.microsoft.com> wrote in message
news:C3**********************************@microsof t.com...

In a default MFC - dialog based application (VC6.0 or VC7.1), the
following
try-catch code does not be catched in Release mode, but it is OK for Debug
mode. Any compiler/link option is required to turn on or turn off?

try
{
int *i = 0;
*i = 0;
}
catch(...)
{
MessageBox("Catched");
}

Thanks in advance,

The problem is that you are confusing structured exceptions and C++ typed
exceptions.

C++ typed exceptions use try and catch.

Win32 structured exceptions, of which division by zero is one, use __try and
__except.

What is happening is that the optimizing sees no possible way that a C++
exception can be thrown in your snippet and so it simply removes it (or
optimizes it away or elides it).

If you link with compile with the /EHa option you inform the compiler that
exceptions can come out of nowhere. The try, catch machinery will not be
removed. And due to what many consider a defect in the compiler, the
structured divide by zero exception will get caught in your catch-all
handler.

If you really need to do this, and I my estimation it is necessary in
development and often unwise otherwise, you should use _set_se_translator()
to translate a structured exception to a typed exception.

By the way, VS2005 does not confuse typed and structured exceptions.

Regards,
Will

[Carl Daniel [VC++ MVP]]

lauch2 wrote:

thanks William,

What is happening is that the optimizing sees no possible way that a
C++ exception can be thrown in your snippet and so it simply removes
it (or optimizes it away or elides it).

Do you mean that it just needs to remove the complier option /O2 in a
default setting for the release build?

Bottom line: Don't expect to catch platform exceptions (e.g. null
reference, divide by zero) using a C++ catch statement - it simply won't
work in all cases.

If you do need to handle platform exceptions in C++ code, you MUST compile
with /EHa, and you SHOULD use __set_se_translator to convert platform
exceptions to C++ exceptions.

Any other combination is simply not guaranteed to work. Ever.

Note that __set_se_translator needs to be called in each thread that wants
to have exceptions translated. Also note that the translator routine you
supply may be called many time during the propagation of a single platform
exception.

-cd

[William DePalo [MVP VC++ ]]

"lauch2" <la****@discussions.microsoft.com> wrote in message
news:E1**********************************@microsof t.com...

thanks William,

You are welcome.

What is happening is that the optimizing sees no possible way that a C++
exception can be thrown in your snippet and so it simply removes it (or
optimizes it away or elides it).

Do you mean that it just needs to remove the complier option /O2 in a
default setting for the release build?

No. The difference in behavior that you experience between the release and
debug builds does stem from the fact that the compiler removes the guard
around the protected section and the exception handler as an optimization.
But it would be akin to throwing the baby out with the bath water if you
were to remove optimizations in a release build to get the debug exception
handling behavior.

As Carl has already pointed out, if you must comingle structured and typed
exceptions then you must use _set_se_translator(). I can post an example
that does that if you need help.

But you must realize that catching the exception is no panacea. It is
possible that a program's state has been so trashed by the time that a
structured execption gets thrown that it is better, for example, to report
the error, create a minidump and exit.

IMO, in development, _set_se_translator() is useful, especially so since the
exception record for structured exceptions includes the address of the bad
code. But later, you really should not confuse structured exceptions which
are almost always evidence of serious programming errors and C++ typed
exceptions which are almost always more benign.

Regards,
Will