Beta2无法捕获异常？ [英] Beta2 can't catch exceptions?
问题描述
我很震惊地得知VC ++ 2005 Beta 2无法访问访问
非托管代码中的违规异常。
重现这一点，我创建了一个最小的Win32控制台应用程序：
#include" stdafx.h"
int _tmain（int argc，_TCHAR * argv [] ）
{
int * p = 0;
试试
{
* p = 0;
}
catch（...）
{
}
返回0;
}
当我用VC ++ 2003或Borland编译器编译和运行它时，
按预期静默捕获异常。使用VC ++ 2005 Beta 2，我得到
系统对话框X.exe遇到问题需要关闭。
[...]调试/发送错误报告/不要发送。就像捕获
块甚至不存在一样。它也不能被零除。
我错过了什么吗？打开C ++异常处理，并且
catch（...）捕获我抛出的其他C ++异常，例如throw
std :: exception（"！" ;）。
Tom
2005年8月24日星期三17:26:46 -0700 ，Tamas Demjen< td ***** @ yahoo.com>写道：
我很震惊地得知VC ++ 2005 Beta 2在非托管代码中无法捕获Access
违规异常。
要重现这个，我创建了一个最小的Win32控制台应用程序：
#include" stdafx.h"
int _tmain（int argc，_TCHAR * argv []）
{
int * p = 0;
尝试
{
* p = 0;
}
catch（...）
{
}
返回0;
}
当我使用VC ++ 2003或Borland编译器编译并运行它时，
异常会按预期静默捕获。使用VC ++ 2005 Beta 2，我得到系统对话框X.exe遇到问题需要关闭。
[...]调试/发送错误报告/不要发送 。就像捕获
阻止甚至不存在一样。它也不能被零除。
我错过了什么吗？ C ++异常处理已打开，并且
catch（...）捕获我抛出的其他C ++异常，例如throw
std :: exception（"！"）。
访问冲突不是C ++例外。简短的回答是VC8
最终修复了这个bug，为了恢复你期望的行为，你需要指定/ EHa而不是/ GX或/ EHSC。现在几个版本实际上已经需要
，以便在发布版本中始终捕获未翻译的SE。
catch（...）。关于这方面的更多内容，并了解为什么
想要捕获SE中的SE（通常是个坏主意），请参阅：
< a rel =nofollowhref =http://members.cox.net/doug_web/eh.htmtarget =_ blank> http://members.cox.net/doug_web/eh.htm
-
Doug Harrison
VC ++ MVP
Tamas Demjen写道：< blockquote class =post_quotes>我很震惊地得知VC ++ 2005 Beta 2在非托管代码中无法捕获Access
Violation异常。
为了重现这一点，我创建了一个最小的Win32控制台应用程序：
#include" stdafx.h"
int _tmain（int argc，_TCHAR * argv []）
{
int * p = 0;
尝试
{
* p = 0;
}
赶上（...）
{
}异常会按预期静默捕获。使用VC ++ 2005 Beta 2，我得到系统对话框X.exe遇到问题需要关闭。
[...]调试/发送错误报告/不要发送 。就像捕获
阻止甚至不存在一样。它也不能被零除。
我错过了什么吗？ C ++异常处理已打开，并且
catch（...）捕获我抛出的其他C ++异常，例如throw
std :: exception（"！"）
为了完成Doug所说的话，尝试忽略
默默地访问违规是一个非常糟糕的主意：AV基本上是一个bug你的代码
可能会使你的程序处于未定义的状态，并试图继续在这些条件下运行
可能是危险的。
这就是为什么当AV为
筹集时，让你的软模更好，并进行验尸调试 - 除非你的应用是
专门设计，以便不同的组件真正隔离
一个来自另一个你确定AV没有任何损坏。
Arnaud
MVP - VC
Doug Harrison [MVP]写道：访问违规行为'' T C ++异常。简短的回答是VC8最终修复了这个bug，并且为了恢复你期望的行为，你需要指定/ EHa而不是/ GX或/ EHsc。现在几个版本实际上已经需要
，以便在发布版本中始终捕获
catch（...）中未翻译的SE。关于这方面的更多内容，并了解为什么一般来说，想要捕获SE中的SE（通常是一个坏主意），请参阅：
http://members.cox.net/doug_web/eh.htm
非常感谢您的回复，这是非常有趣的，并且是一个基本的改变我所经历过的经历过去的十年。
我发现这可能很危险，但是有可能发生崩溃和数据总损失
因为一个微不足道的错误，99％的情况不会影响
计划有点苛刻。例如，OCR enigne中的崩溃将导致所有文本实体在*最差*
情况下丢失特定页面。这些错误会被捕获并记录下来，因此有关于它的
警告。如果这是一个应用程序级别的问题，那么列表框中可能会丢失项目
，或类似的，但用户仍然可以保存退出之前的文件。我不会盲目地捕捉AV，
而不让用户知道它们。弹出一个对话框
up，或记录错误，或两者都有。
无论如何，我理解这个概念，这是一个非常有用的反馈。我赞赏它。
Tom
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
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
这篇关于Beta2无法捕获异常？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
