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 11 1470
On Wed, 24 Aug 2005 17:26:46 -0700, Tamas Demjen <td*****@yahoo. com> wrote: 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 ("!").
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
--
Doug Harrison
VC++ MVP
Tamas Demjen wrote: 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( "!")
To complete what Doug has said, it's a *very* bad idea to try to ignore
silently an Access Violation : An AV is basically a bug in your code
that may put your program in an undetefined state, and trying to
continue to run in those conditions could be dangerous.
That's why it's generally better to let your soft die when an AV is
raised, and do a post-mortem debugging - unless your app is
specifically designed so that different components are really isolated
one from the other and you're certain the AV hasn't corrupted anything.
Arnaud
MVP - VC
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. 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. 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.
Tom
Tamas Demjen wrote: 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. For example, a crash in the OCR enigne will cause all text entities to be lost for a particular page in the *worst* case.
No : A rogue pointer writing may do anything to your app : in the *worst*
case, you may corrupt the heap manager, TEB, handle descriptor or any other
vital data structure.
Arnaud
MVP - VC
"Tamas Demjen" <td*****@yahoo. com> wrote in message
news:O8******** ******@TK2MSFTN GP09.phx.gbl... 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. 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. 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.
FWIW: Where structured exceptions and C++ are concerned, Doug's essay sums
it up much better than I could. That said, however, in development, or
perhaps in production where you are faced with a pernicious but elusive SE
raised by some component for which you don't have source, you might have a
valid reason to "translate" the SE to a C++ typed exception so that you can
handle it as you describe above.
This thread shows one way to do that: http://groups.google.com/group/micro...aa89b74adeeeab
Regards,
Will
Arnaud Debaene wrote: No : A rogue pointer writing may do anything to your app : in the *worst* case, you may corrupt the heap manager, TEB, handle descriptor or any other vital data structure.
I realize the danger, no question about that, that's why I never want a
completely silent handling of AVs. In fact, I want an annoying or scary
message that makes the customer report it to us.
However, I thought a rogue pointer would either cause corruption in the
heap/stack *without* an AV, which remains completely unnoticed until
later in time, or it causes an AV, in which case there is no corruption
whatsoever (the AV itself prevents any corruption). So while an AV is a
sign of programming error that may cause corruption, at the time of the
AV it doesn't.
In my practice, these uncaught exceptions are often either AV due to
NULL pointer dereference, or division by 0 due to unknown resolution
value in an image, or similar programming erros, which often are not
enough for an immediate crash that causes all data to be lost.
I see the danger, and it's a good idea to rethink how we handle access
violations.
Probably the ideal way of handling these errors would be the following:
1. save all data to a recovery file
2. show an error message to the customer that a critical error occured
and the author should be notified
3. exit the application immedaitely
4. the next time the application launches, it recognizes the recovery
data and offers the user for loading/recovering
In an embedded system or mission critical system, maybe log the error,
reboot, and start an auto-recovery.
Tom
Tamas Demjen wrote: However, I thought a rogue pointer would either cause corruption in the heap/stack *without* an AV, which remains completely unnoticed until later in time, or it causes an AV, in which case there is no corruption whatsoever (the AV itself prevents any corruption). So while an AV is a sign of programming error that may cause corruption, at the time of the AV it doesn't.
Actually an AV can be a result of a previously unnoticed stack/heap
corruption, and the memory may already be corrupt at that time. It makes
sense to be cautious...
Tom
On Thu, 25 Aug 2005 09:18:30 -0700, Tamas Demjen <td*****@yahoo. com> wrote: Thanks a lot for your reply, it's very interesting and is a fundamental change to what I've experienced during the past decade.
Which is literally about as long as I've been trying to get this bug fixed.
:)
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. 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. 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.
In that case, I hope you don't overwrite an existing (good) file with the
potentially corrupted data, and I hope you warn the user the file you do
save may contain corrupted data. If you allow the program to continue, you
should also disclose that you have no idea what state it's in, so the user
necessarily proceeds at his own risk and should be prepared to run into
other problems later on that may or may not have anything to do with the
prior bug swallowing event, which, in this day and age, may have opened up
unspeakable security holes.
Anyway, I understand the concept, it was a very useful feedback. I appreciate it.
You're welcome. Many people have resisted the ideas I wrote about far more
vehemently than you. :)
--
Doug Harrison
VC++ MVP
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. ;-)
Tom This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics |
by: dkcpub |
last post by:
I'm very new to Python, but I couldn't find anything in the docs or faq
about this. And I fished around in the IDLE menus but didn't see anything.
Is there a tool that can determine all the exceptions that can be raised
in a Python function, or in any of the functions it calls, etc.?
/Dan
|
by: Tom Groszko |
last post by:
Given a try catch scenario
try
{ dosomething();
}
catch (...)
{ report some error
}
Is there any way to figure out what exception is being thrown and
|
by: Steven T. Hatton |
last post by:
If I understand correctly, I have no assurance that I can determine the type
of a simple class instance thrown as an exception unless I explicitly catch
it by name. (non-derived classes having no virtual funcitons have no rtti)
That is, there is no way to do something like:
try{
funct_from_3rd_party();
}
catch(...){
std:err <<...
|
by: Z D |
last post by:
Hi,
I was wondering what's the point of "finally" is in a try..catch..finally
block?
Isn't it the same to put the code that would be in the "finally" section
right after the try/catch block? (ie, forget the finally block and just end
the try/catch and put the code after the try/catch block).
Or does the "finally" construct add some...
|
by: Rob Richardson |
last post by:
Greetings!
I am working on an application that targets a Pocket PC running Windows CE
and SQL Server CE. Almost all functions in the application use a Try block
with a Catch block that looks like this:
Try
TryToDoIt()
Catch e as Exception
LogTheError(e)
| |
by: l.woods |
last post by:
I want to set up my CATCH for a specific exception, but I really don't know
which one of the multitude that it is. I am getting the exception now with
Catch ex as Exception
but I want to be more specific. I can't find any property of the exception
object that tells me WHICH one it is.
TIA,
|
by: Mr Flibble |
last post by:
Are
try
{
//something
}
catch
{
//
}
|
by: tommaso.gastaldi |
last post by:
It would be useful, sometimes, when debugging, to disable
all the try /catch one has in the program (clearly not commenting them
out).
Any info or hint on that?
-tom
|
by: Tony |
last post by:
Well the subject says it all. Do I have to have it if I use classes in C++?
Tony
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
| |
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| |
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
| |