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
当你处理异常能.如果分配失败,并且您的应用程序无法在没有该内存的情况下继续,为什么还要检查错误?
当有一种有意义的恢复方法时,处理可以处理的错误.如果你无法对错误做任何事情,那就让它传播吧.
我通常会在用户发起操作时捕获异常.对于控制台应用程序,这意味着main,对于GUI应用程序,我将处理程序放在诸如按钮点击处理程序之类的位置.
我认为在动作中捕获异常没有多大意义,用户通常希望操作成功或完全失败.
| 归档时间: |
|
| 查看次数: |
9197 次 |
| 最近记录: |