Exception Handling in Release Mode

[Mohan]

Hi,

I am learning the Exception Handling in C++. I wrote a small program using

Exception Handling. I am using Vistual Studio 6.

It is working fine in Win32 Debug build, but it is not catching the

exception in Win32Release mode.
int main(int argc, char* argv[])
{
int i = 0;

try
{
int m = 17/i;
}
catch(...)
{
cout<<"Main - Catch"<<endl;
}
cout <<"End of Main" <<endl;

return 0;
}
Could you please explain, why the Exception is not caught in the
Win32Release mode.??
Thanks
Mohan

[Rolf Magnus]

Mohan wrote:

Hi,

I am learning the Exception Handling in C++. I wrote a small program
using

Exception Handling. I am using Vistual Studio 6.

It is working fine in Win32 Debug build, but it is not catching the

exception in Win32Release mode.
int main(int argc, char* argv[])
{
int i = 0;

try
{
int m = 17/i;
}
catch(...)
{
cout<<"Main - Catch"<<endl;
}
cout <<"End of Main" <<endl;

return 0;
}
Could you please explain, why the Exception is not caught in the
Win32Release mode.??

Division by zero invokes undefined behavior, so anything might happen. The
C++ standard doesn't require an exception to be thrown. My guess would be
that your compiler adds an extra check in "Debug" mode, and "Win32Release"
mode, it's left out for efficiency reasons.

[Andre Kostur]

"Mohan" <ra*******@rediffmail.comwrote in
news:er**********@daniel-new.mch.sbs.de:

Hi,

I am learning the Exception Handling in C++. I wrote a small program
using

Exception Handling. I am using Vistual Studio 6.

It is working fine in Win32 Debug build, but it is not catching the

exception in Win32Release mode.
int main(int argc, char* argv[])
{
int i = 0;

try
{
int m = 17/i;

Division by zero. Undefined Behaviour. Anything can happen here. Just
happens in your case that something that kinda looks like an exception is
thrown.

}
catch(...)
{
cout<<"Main - Catch"<<endl;
}
cout <<"End of Main" <<endl;

return 0;
}
Could you please explain, why the Exception is not caught in the
Win32Release mode.??

From a C++ Standard point of view, no. Since division by zero invokes
Undefined Behaviour, we cannot speculate on what may happen. (However,
look up Structured Exception Handling in your compiler's documentation.
No, it's not a real C++ exception. And is off-topic for this newsgroup.
Further questions on SEH should be directed to a Microsoft newsgroup.)

[Lionel B]

On Thu, 15 Feb 2007 14:59:29 +0700, Mohan wrote:

Hi,

I am learning the Exception Handling in C++. I wrote a small program using

Exception Handling. I am using Vistual Studio 6.

It is working fine in Win32 Debug build, but it is not catching the

exception in Win32Release mode.
int main(int argc, char* argv[])
{
int i = 0;

try
{
int m = 17/i;

Divide by zero is not guaranteed to throw a C++ exception - no idea why it
appears to do so in VC++ 6 debug mode.

Also, be aware that the VC++ 6 compiler is very old, buggy and not very
standards-compliant - think about getting hold of a more modern compiler.

[...]

--
Lionel B

[Grizlyk]

Mohan wrote:

It is working fine in Win32 Debug build, but it is not catching the
exception in Win32Release mode.

1.
In the code

try
{
int m = 17/i;
}

"m" is assigned, but never used, and in "Win32Release mode" can be optimized
and the try block can be removed. To always get the error, place the "int
m=0;" declaration into global scope.

2.
You can try to use signals and manual trap points, but it is not beauty
solution and not always work.

#include <signal.h>
int trap_point=0;

extern "C" void your_signal_handler(int)
{
signal(SIGFPE,your_signal_handler);
cout<<"SIGFPE catched"<< endl;

//here system-depended can you continue after signal or not
//CPU and OS mostly can, because they store
//point of execution of synced hardware exception
//but C++ library not always use the data correctly
}

int main(int argc, char* argv[])
{
int i = 0;

signal(SIGFPE,your_signal_handler);

>
try
{

enum {THE_POINT=1};
trap_point=THE_POINT;

int m = 17/i;

//Here SIGFPE can be catched and processed to continue execution
if( !trap_point )throw THE_POINT;

}
catch(...)
{
cout<<"Main - Catch"<<endl;
}
cout <<"End of Main" <<endl;

return 0;
}

--
Maksim A. Polyanin

"In thi world of fairy tales rolls are liked olso"
/Gnume/

[ruediger.meyer]

On 15 Feb., 08:59, "Mohan" <[e-mail]:

Hi,

I am learning the Exception Handling in C++. I wrote a small program using

Exception Handling. I am using Vistual Studio 6.

It is working fine in Win32 Debug build, but it is not catching the

exception in Win32Release mode.

int main(int argc, char* argv[])
{
int i = 0;

try
{
int m = 17/i;
}
catch(...)
{
cout<<"Main - Catch"<<endl;
}
cout <<"End of Main" <<endl;

return 0;

}

Could you please explain, why the Exception is not caught in the
Win32Release mode.??

Thanks
Mohan

m is never used, so the compiler removes the computation of the
division. No division, no exception.
replace return 0; with return m; to force the compiler to do the
division, then is should work.
Rüdiger

[Lionel B]

On Wed, 21 Feb 2007 08:20:59 -0800, ruediger.meyer wrote:

On 15 Feb., 08:59, "Mohan" <[e-mail]:

>Hi,

I am learning the Exception Handling in C++. I wrote a small program using

Exception Handling. I am using Vistual Studio 6.

It is working fine in Win32 Debug build, but it is not catching the

exception in Win32Release mode.

int main(int argc, char* argv[])
{
int i = 0;

try
{
int m = 17/i;
}
catch(...)
{
cout<<"Main - Catch"<<endl;
}
cout <<"End of Main" <<endl;

return 0;

}

Could you please explain, why the Exception is not caught in the
Win32Release mode.??

Thanks
Mohan

m is never used, so the compiler removes the computation of the
division. No division, no exception.

Again: C++ does not require that an exception be thrown for a divide by
zero. So there is no guarantee that this will throw an exception on any
particular C++ implementation.

In fact if I compile and run the above on my system (happens to be gcc on
linux) it prints out:

Floating point exception

and the program terminates (whether m is "used" or not). In other words,
*no C++ exception is thrown* by the divide by zero (rather it appears that
the runtime system traps the divide by zero and causes the program to
terminate, perhaps by sending it some signal... but that's by-the-by).

replace return 0; with return m;

Ummm... did you actually try that (won't compile, of course, as m is out
of scope at the return statement).

to force the compiler to do the division, then is should work.

.... for some strange value of "work"

--
Lionel B