我注意到在我的公司里,人们似乎过度使用异常.用例示例:
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
它们允许集中处理错误
他们可能会携带有关错误的更多信息,而不是简单的字符串
为了解决您的问题:
例外使代码看起来像一团糟
如果将代码与正确的异常处理进行比较,那么在遇到意外情况时,代码会简单地放弃并死掉(或者更糟糕的是,继续进入UB),然后是.但这不是一个公平的比较.通过第二种选择节省的努力是否值得,由您和您的公司决定.
如果在库中创建例外,则必须在程序中检查它们,否则它们将无用
再一次,替代方案是什么?检查错误代码是方式更加膨胀.如果图书馆崩溃你的程序是首选吗?
您必须在某些情况下检查几十个可能的例外情况.
如果异常是多态的(比如标准异常),这很容易避免.如果您的库抛出了20个不共享公共基类的异常,请向库供应商投诉.否则,您可以选择是否要一起处理它们("库中的问题:",然后是错误代码/消息)或实际过滤它们.
处理线程中的异常是棘手的
只不过线程本身是棘手的.在某些情况下,你必须要小心,或者预制算法不能很好地处理它们,但那是你的线程.
我怎么想念异常?
异常的核心思想是,您可以在遇到它们时安全地恢复正常/其他操作.例外可以很容易地编写不会泄漏内存的代码,在发生可恢复的错误时输入UB等.
即使您确定所有错误都是不可恢复的并且不进行异常处理,未处理的异常将1.为错误的位置提供堆栈跟踪,并产生一些希望有用的调试消息.断言可能会这样做,但通常在发布版本中被禁用,因此您将有0防止在那里运行到UB.
| 归档时间: |
|
| 查看次数: |
115 次 |
| 最近记录: |