SEH 错误报告
我有一个 Visual Studio 2008 C++ 程序,该程序被包装在 __try
/__ except
块中以捕获任何 SEH 异常。异常过滤器创建错误日志并向用户提供有关如何提交缺陷报告的详细说明。
过滤器中的代码是否需要包装在另一个 __try
/__ except
块中?如果不是,如果例外的话会发生什么?如果是的话,应该如何处理?
static int MyFilter( struct _EXCEPTION_POINTERS* ep )
{
/*
Code to log the exception information, and instruct the user
on how to submit a defect report. Should this be in another
__try/__except block?
*/
return EXCEPTION_EXECUTE_HANDLER;
}
int WINAPI _tWinMain( HINSTANCE hInstance,
HINSTANCE /*hPrevInstance*/,
LPTSTR lpstrCmdLine,
int nCmdShow )
{
int result = 0;
__try
{
result = Execute( hInstance, lpstrCmdLine, nCmdShow );
}
__except( MyFilter( GetExceptionInformation() ) )
{
// empty
}
return 0;
}
谢谢, PaulH
编辑: 如果 MyFilter
引发异常,那么我就会进入无限异常循环。所以,看起来确实需要 __try
/__ except
处理。我正在考虑这样做:
static int MyFilter( struct _EXCEPTION_POINTERS* ep )
{
__try
{
/*
Code to log the exception information, and instruct the user
on how to submit a defect report.
*/
// cause an exception
int x = 0, y = 1 / x;
}
__except( EXCEPTION_EXECUTE_HANDLER ) { /*empty*/ }
return EXCEPTION_EXECUTE_HANDLER;
}
在这种情况下,程序应该异常终止,并且异常应该传递给操作系统来处理。这是正确的吗?
I have a Visual Studio 2008 C++ program where the program is wrapped in a __try
/__except
block to capture any SEH exceptions. The exception filter creates an error log and gives the user detailed instructions on how to submit a defect report.
Does the code within the filter need to be wrapped in another __try
/__except
block? If not, what happens if it excepts? If so, how should that be handled?
static int MyFilter( struct _EXCEPTION_POINTERS* ep )
{
/*
Code to log the exception information, and instruct the user
on how to submit a defect report. Should this be in another
__try/__except block?
*/
return EXCEPTION_EXECUTE_HANDLER;
}
int WINAPI _tWinMain( HINSTANCE hInstance,
HINSTANCE /*hPrevInstance*/,
LPTSTR lpstrCmdLine,
int nCmdShow )
{
int result = 0;
__try
{
result = Execute( hInstance, lpstrCmdLine, nCmdShow );
}
__except( MyFilter( GetExceptionInformation() ) )
{
// empty
}
return 0;
}
Thanks,
PaulH
Edit:
If MyFilter
raises an exception, then I get in to an infinite exception loop. So, it looks like it does need __try
/__except
handling. I'm looking at doing this:
static int MyFilter( struct _EXCEPTION_POINTERS* ep )
{
__try
{
/*
Code to log the exception information, and instruct the user
on how to submit a defect report.
*/
// cause an exception
int x = 0, y = 1 / x;
}
__except( EXCEPTION_EXECUTE_HANDLER ) { /*empty*/ }
return EXCEPTION_EXECUTE_HANDLER;
}
In this case, the program should have an abnormal termination and exception should be passed up to the OS for it to deal with. Is that correct?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
如果您在过滤器中引发异常,您将再次进入过滤器方法。您的异常将由同一个 __except 块处理。
但是在过滤器方法中使用另一个 __try __ except 块没有问题。
不幸的是我不能给你任何关于这一点的参考。我刚刚亲自尝试过,你也可以。只需强制除以零即可。
通常我不使用 SEH,但有几次我在过滤方法中引发异常时没有遇到任何问题。但我在msdn中查找时没有找到任何内容。
If you raise an exception in your filter you will end up in the filter method again. Your exception will be handled by the same __except block.
But there is no problem in using another __try __except block in your filter method.
Unfortunately I cannot give you any references to this. I just tried it my self and you can too. Just force an division by zero.
Usually I do not use SEH but the few times I did I had no issues in raising an exception in the filter method. But I did not find anything in the msdn when I looked for this.
执行此操作时有很多事情需要注意。当您的 SEH 处理程序运行时,您的进程处于完全未知的状态,并且您尝试指导用户执行的某些操作可能会失败。例如,如果异常是堆栈溢出,那么您在这里几乎无能为力。如果您在这里使用 UI 框架(例如 MFC),它可能会损坏或处于不一致的状态,因为您的应用程序可能在某些重要操作中途崩溃。如果您的应用程序是多线程的,您需要知道当您进入此过滤器时,其他线程仍将运行,并且可以小心处理。
如果您确实需要执行此操作,一种替代方法是使用看门狗进程来执行此操作。
There are lots of things you need to be careful of when doing this. When your SEH handler runs, your process is in a completely unknown state and some of the things you try to do to instruct the user may fail. For example, if the exception was a stack overflow, there is very little you can do here. If you use a UI framework (MFC say) in here, it might be broken or in an inconsistent state because your app could have crashed mid way through some significant operation. If your app is multithreaded you need to know that those other threads will still be running when you get in to this filter, and handling that may take care.
If you really need to do this, one alternative approach is to have a watchdog process to do it.