C++中异常的核心优势

dgr*_*rat 1 c++ exception

我注意到在我的公司里,人们似乎过度使用异常.用例示例:

void check(size_t s, int64_t i) 
{
  if (i < 0 || size_t(i) >= s)
  {
    stringstream st;
    st << "bar";
    throw Exception (st.str());
  }
}

foo & operator() (size_t i) const
{
    // access out of range?
    check(s,i);
    return data[i]; 
}
Run Code Online (Sandbox Code Playgroud)

我认为,上面的例子应该用断言替换,因为程序最终会在UB中.(这不是一个必须继续工作以保持人们活着和/或使用传感器输入的系统).

  • 处理线程中的异常是棘手的
  • 特定于库的(非标准)异常定义需要在程序中进行特殊处理
    • 使用几个具有自己的异常类型的库..
    • 您必须在某些情况下检查几十个可能的例外情况.

我怎么想念异常?例如核心优势是什么?为什么要将错误处理拆分成程序和库?

小智 5

例外的一些优点:

  • 它们可以被捕获并且错误可能在没有程序终止的情况下处理

  • 他们保证堆栈展开 - assert简单地调用abort

  • 它们允许集中处理错误

  • 他们可能会携带有关错误的更多信息,而不是简单的字符串

  • @dgrat:不是我的公司不是.不继承`std :: exception`也是相当应受谴责的,除非你有充分的理由不这样做.进一步研究还揭示了C++标准库中定义的开箱即用的超出范围异常,那么为什么要自己动手?故事的寓意是你不能从阴沟中学习C++. (2认同)

Max*_*hof 5

为了解决您的问题:

例外使代码看起来像一团糟

如果将代码与正确的异常处理进行比较,那么在遇到意外情况时,代码会简单地放弃并死掉(或者更糟糕的是,继续进入UB),然后是.但这不是一个公平的比较.通过第二种选择节省的努力是否值得,由您和您的公司决定.

如果在库中创建例外,则必须在程序中检查它们,否则它们将无用

再一次,替代方案是什么?检查错误代码是方式更加膨胀.如果图书馆崩溃你的程序是首选吗?

您必须在某些情况下检查几十个可能的例外情况.

如果异常是多态的(比如标准异常),这很容易避免.如果您的库抛出了20个不共享公共基类的异常,请向库供应商投诉.否则,可以选择是否要一起处理它们("库中的问题:",然后是错误代码/消息)或实际过滤它们.

处理线程中的异常是棘手的

只不过线程本身是棘手的.在某些情况下,你必须要小心,或者预制算法不能很好地处理它们,但那是你的线程.

我怎么想念异常?

异常的核心思想是,您可以在遇到它们时安全地恢复正常/其他操作.例外可以很容易地编写不会泄漏内存的代码,在发生可恢复的错误时输入UB等.

即使您确定所有错误都是不可恢复的并且不进行异常处理,未处理的异常将1.为错误的位置提供堆栈跟踪,并产生一些希望有用的调试消息.断言可能会这样做,但通常在发布版本中被禁用,因此您将有0防止在那里运行到UB.