Beta2 can't catch exceptions?

[Tamas Demjen]

I was shocked to learn that VC++ 2005 Beta 2 can't catch Access
Violation exceptions in unmanaged code.

To reproduce this, I created a minimal Win32 console application:

#include "stdafx.h"

int _tmain(int argc, _TCHAR* argv[])
{
int* p = 0;
try
{
*p = 0;
}
catch(...)
{
}
return 0;
}

When I compile and run this with VC++ 2003 or a Borland compiler, the
exception is caught silently as expected. With VC++ 2005 Beta 2, I get
the system dialog "X.exe has encountered a problem and needs to close.
[...] Debug / Send Error Report / Don't Send". Just like if the catch
block wasn't even there. It can't catch divide by zero either.

Am I missing something? C++ exception handling is turned on, and
catch(...) catches other C++ exceptions that I throw, such as throw
std::exception( "!").

Tom

[Peter Koch Larsen]

"Tamas Demjen" <td*****@yahoo. com> skrev i en meddelelse
news:O8******** ******@TK2MSFTN GP09.phx.gbl...

Doug Harrison [MVP] wrote:

Access violations aren't C++ exceptions. The short answer is that VC8
finally fixes this bug, and to restore the behavior you're expecting, you
need to specify /EHa instead of /GX or /EHsc. That's actually been
required
for several versions now in order to consistently catch untranslated SEs
in
catch(...) in release builds. For much more on this, and to understand
why
it's generally a bad idea to want to catch SEs in catch(...), see:

http://members.cox.net/doug_web/eh.htm
Thanks a lot for your reply, it's very interesting and is a fundamental
change to what I've experienced during the past decade.

I see that it can be dangerous, but risking a crash and total data loss
for an insignificant error that 99% of the cases doesn't affect the
program is a bit harsh.

Do you call dereferencing a null-pointer insignificant?
For example, a crash in the OCR enigne will cause all text entities to be lost for a particular page in the *worst*
case. Those errors are caught in the catch and are logged, so there is
warning about it. Well.. if you are using software, that dereferences null pointers, all bets
are off, arent they?

If it's an application level problem, then maybe items will be missing from a list box, or similar, but the user will still be
able to save the document before exiting. I don't blindly catch AVs,
without letting the user know about them. Either a dialog box is popped
up, or the error is logged, or both.

Anyway, I understand the concept, it was a very useful feedback. I
appreciate it.
My recommendation is that you - if you really, really have to use such
unreliable software components, at least run them in another process. Tom

/Peter

[Andre Kaufmann]

Tamas Demjen wrote:

Doug Harrison [MVP] wrote:

You're welcome. Many people have resisted the ideas I wrote about far
more
vehemently than you. :)

I'm convinced. It made me think for a while, and yes, initially I had
mixed feelings about it. AVs seemed innocent enough in the past, and
customers always took it as serious as a crash, reporting it right away.
I just have no way of knowing how many times I silenced an AV. ;-)

The coolest thing about how Windows handles access violations are that
it writes dump files. Windows will send them to Microsoft / the developer.
The dump file may be loaded directly in the VC IDE and enables the
developer to debug the application and the cause of the access violation.

Another cool thing is that Windows Vista task manager now has a context
menu "Write dump file". So that the state of a running application
showing errors, but no crashs, may be analyzed in the IDE.

Andre