捕获std :: bad_alloc的策略

Eva*_*ran 12 c++ coding-style try-catch new-operator

所以我在开发中使用Qt并且非常喜欢它.Qt对象的通常设计模式是使用它们来分配它们new.

几乎所有示例(尤其是Qt设计器生成的代码)都不会检查std::bad_alloc异常.由于分配的对象(通常是小部件等)很小,因此这几乎不成问题.毕竟,如果你没有分配20个字节之类的东西,那么你可以做的事情并不多,无法解决问题.

目前,我采用了一种策略,即在try/catch中包装"large"(大小超过一页或两页)分配.如果失败了,我会向用户显示一条消息,几乎任何更小的消息,我只会让应用程序崩溃并出现std::bad_alloc异常.

所以,我想知道这方面的思想是什么?

检查每一项new操作是否是好政策?或者只有我希望有可能失败的?

此外,在处理资源可能受到更多限制的嵌入式环境时,这显然是一个完全不同的故事.我在桌面应用程序的上下文中询问,但也会对涉及其他场景的答案感兴趣.

APr*_*mer 17

问题不在于"捕获的地方",而是"捕获异常时该怎么办".

如果你想检查,而不是包装与try catch你更好地使用

    #include <new>
    x = new (std::nothrow) X();
    if (x == NULL) {
        // allocation failed
    }
Run Code Online (Sandbox Code Playgroud)

我通常的做法是

  • 在非交互式程序中,捕获主级别并在那里显示适当的错误消息.

  • 在具有用户交互循环的程序中,也在循环中捕获,以便用户可以关闭某些东西并尝试继续.

在特殊情况下,还有其他地方捕获有意义,但这种情况很少见.


jal*_*alf 11

当你处理异常.如果分配失败,并且您的应用程序无法在没有该内存的情况下继续,为什么还要检查错误?

当有一种有意义的恢复方法时,处理可以处理的错误.如果你无法对错误做任何事情,那就让它传播吧.


ava*_*kar 6

我通常会在用户发起操作时捕获异常.对于控制台应用程序,这意味着main,对于GUI应用程序,我将处理程序放在诸如按钮点击处理程序之类的位置.

我认为在动作中捕获异常没有多大意义,用户通常希望操作成功或完全失败.