使用catch（...）（省略号）进行事后分析 [英] using catch(...) (ellipsis) for post-mortem analysis

问题描述

有人在一个不同的问题建议使用 catch（...）捕获所有否则未处理的意外/不可预见的异常通过围绕整个主（）与 try {} catch（...）{} 块。

这听起来像一个有趣的想法，可以节省很多时间调试程序，并留下至少一个提示的发生了什么。

问题的本质是< （除了我抛弃的任何调试全局变量之外），以及如何恢复它（如何访问和识别被调用的catch）。 p>

此外，与它相关的注意事项。特别是：

• 它会在以后发芽的线程上播放吗？


• 处理segfaults（在别处捕获信号）


• 将不会影响其他try ... catch块不可避免地嵌套在里面，那么是否可以处理预期的异常？

解决方案

是的，这是一个好主意。

一个异常逃逸主要是实现定义天气堆栈在应用程序关闭之前解开。所以在我看来，你必须捕获所有的异常在主要。

这个问题就变成了对他们做什么。

有些操作系统MS和SE）提供了一些额外的调试工具，所以在捕获异常之后重新抛出异常是很有用的（因为堆栈现在已经解开了）。

  int main（）
 {
 try 
 {
 ///所有真实代码
} 
 // I看到点捕获其他异常在这一点
 //（除了更好的日志可能）。如果异常可能被捕获
 //并且固定，您应该在此之前完成它。 
 
 catch（std :: exception const& e）
 {
 // Log e.what（）比...更好的错误信息... 
 throw; 
} 
 catch（...）//捕获所有异常。强制堆叠正确展开。 
 {
 //你可能想记录一些似乎有礼貌的东西。 
 throw; //重新抛出异常，所以操作系统给你一个调试机会。 
} 
} 
  

• 它会在以后发芽的线程上播放吗？

线程。通常你必须手动加入任何子线程，以确保他们已经退出。当主退出没有很好定义时，子线程的确切细节（所以读取你的文档），但通常所有的子线程将立即死亡（一个讨厌的可怕的死亡，不涉及解开他们的堆栈）。

如果你正在谈论子线程中的异常。再次，这没有很好地定义（所以读取您的文档），但如果线程退出通过异常（即用于启动线程退出的函数，因为一个异常而不是一个返回），这通常会导致应用程序终止（相同的影响如上）。

信号不受异常影响处理机制。

但是因为信号处理程序可能在堆栈上放置一个奇怪的结构（为了自己返回处理正常代码），这不是一个好主意在信号处理程序中抛出异常可能会导致意外的结果（并且绝对不可移植）。

不应该影响其他处理程序。

Someone in a different question suggested using catch(...) to capture all otherwise unhandled - unexpected/unforseen exceptions by surrounding the whole main() with the try{}catch(...){} block.

It sounds like an interesting idea that could save a lot of time debugging the program and leave at least a hint of what happened.

The essence of the question is what information can be recovered that way (other than whatever debug globals I leave behind), and how to recover it (how to access and recognize whatever catch was called with)

Also, what caveats are connected with it. In particular:

• will it play nice with threads that sprout later?
• will it not break handling segfaults (captured elsewhere as signal)
• will it not affect other try...catch blocks inevitably nested inside, that are there to handle expected exceptions?

解决方案

Yes it is a good idea.

If you let an exception escape main it is implementation defined weather the stack is unwound before the application is shut down. So in my opinion it is essential you catch all exceptions in main.

The question then becomes what to do with them.
Some OS (See MS and SE) provide some extra debugging facilities so it is useful to just re-throw the exception after you catch it (because the stack has been unwound now anyway).

int main()
{
    try
    {
        /// All real code
    }
    // I see little point in catching other exceptions at this point 
    // (apart from better logging maybe). If the exception could have been caught
    // and fixed you should have done it before here.

    catch(std::exception const& e)
    {
         // Log e.what() Slightly better error message than ...
         throw;
    }
    catch(...)   // Catch all exceptions. Force the stack to unwind correctly.
    {
        // You may want to log something it seems polite.
        throw;  // Re-throw the exception so OS gives you a debug opportunity.
    }
}

• will it play nice with threads that sprout later?

It should have no affect on threads. Usually you have to manually join any child threads to make sure that they have exited. The exact details of what happens to child threads when main exits is not well defined (so read your documentation) but usually all child threads will die instantly (a nasty and horrible death that does not involve unwinding their stacks).

If you are talking about exceptions in child threads. Again this is not well defined (so read your documentation) but if a thread exits via an exception (ie the function used to start the thread exits because of an exception and not a return) then this usually causes the application to terminate (same affect as above). So it is always best to stop ALL exceptions from exiting a thread.

• will it not break handling segfaults (captured elsewhere as signal)

Signals are not affected by the exception handling mechanism.
But because signal handlers may place an odd structure on the stack (for their own return handling back to normal code) it is not a good idea to throw an exception from within a signal handler as this may cause unexpected results (and is definitely not portable).

• will it not affect other try...catch blocks inevitably nested inside, that are there to handle expected exceptions?

Should have no effect on other handlers.

这篇关于使用catch（...）（省略号）进行事后分析的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！