d比较错误和异常2

原文
我不知道在单元测试块和合同中抓错误行为不一样.
一个反馈是非主线程.尽管都同意不应抓错误,但主线程会这样并打印文章中显示的有用输出.
如果允许主线程这样做,也应在非主线程做同样多(或更少)的事情.否则,无法跟踪线程.

如果偏执并想尽量少做,至少应复制串字面到stderr.类似"线程因错误退出".然后退出(1).
不抓错误的规则,是打印诊断信息.但此后,不应继续运行程序.

如果线程未抓错误并结束程序,这是运行时缺陷.
我过去认为不应抛错误,而是记录错误(包括调用栈),然后甚至不展开栈的退出.但是代码至少期望抛错误栈,这样期望抓它的代码会中断.

除非用std.concurrency,且主线程查找并接收LinkTerminated消息(用spawnLinked启动线程).

void myThread() {
  try {

  } catch (Exception exc) {
     // ...

  } catch (Error exc) {
    // 报告错误
    exit(1); // 退出或其他
  }
}

一般,不必继承Error.用户代码中抛错误的最常见的方法是使用assert,它(有默认编译器标志)在失败时抛AssertError.函数合同和构/类不变量工作方式相同

可提供必须抛错误而不能抛适当异常代码吗?

这完全是设计API的问题.如果调用者在调用函数前检查某些条件,则可在条件不成立时抛Error(或更有可能使用assert或in合同来检查它).如果是被调用者检查,则应抛Exception(或使用enforce).

Error的要点是代码可假定它不会发生,如果发生了,则代码无效.
反映在编译器,则在抛错误时,会省略清理代码(可假设它永远不会).使用Error目的是最后检查程序正确性(因为在到达该点前未能验证输入).

如果抛错误,vibe应退出.在vibe代码中总是困扰我的是,越界数组错误.我用抛异常包装器替换了一些数组,因为有时我不想使整个服务器崩溃,也不想连续验证数组索引.

只要未抓到可抛或错误,就应该没问题.简单不标记事物为nothrow,并不表明它们不会按nothrow推导.auto和模板函数都是推导出来.
可能很少会咬到你.但也表明,如果它真的咬人,那真的很难追踪.
正如Paul所说,这根据你的API.如果假定已清理函数输入,如果超出规范,则可正确抛错误.

很好示例是区间函数.你经常会在popFront方法的开头,看到assert(!empty);语句.这是普遍接受的,因为如果不检查empty,则不应调用popFront.

不应重试错误,且不应抛错误.
OutOfMemoryError不应是错误,而是异常.因为无法在分配前检查分配是否成功,并且,有些方法可在不关闭进程就处理内存不足问题.
可抓并重试异常.预测失败,然后抛异常是可行的.
100%安全,在具有最小共享内存的单独进程中运行它.

你不假定它,你保证它.你要向编译器保证代码不会抛错误.
但是你并不完美,所以可能犯了错误,并触发了错误(Error).编译器展开栈并回到主函数,打印错误并退出,因此可修复你犯的错误.
类似段错误.不应该读取不拥有的内存(是的,我知道可用段错误来触发加载内存,我不是在谈论那种段错误).则当意外段错误时怎么做?崩溃程序,然后退出.这里,默认,语言会为你提供有关位置提示,还可在所需位置抓错误并检查更多等,来取更多信息.

但是,我确实向Walter询问了这个问题,他说要像goto一样对待抛/抓错误.
错误的意义在于可删除它们来提高效率.即,就像断定或检查边界一样,它们不应成为正常程序的一部分.而异常是程序的一部分,并提供了不同机制来处理错误.

但是可关闭断定并使代码运行得更快.我个人从不在某些程序(网络服务器)上关闭它们,因为代价不够明显.但如果这些是异常,就不能关闭它们.

考虑foreach循环中区间的正常流:

// foreach(elem; range)
for(auto r = range; !r.empty; r.popFront) {
    auto elem = r.front;
}

如果popFront和front两者都调用empty,则每个循环调用3次empty,第2次和第3次调用值相同.有了断定可在不崩溃程序下就诊断无效程序,而且还可在需要时提供完整性能.

d的标准库的红黑树有个遍历整个RBT并在每个方法调用之前和之后,验证红黑树invariant属性的方法.这不是你想要的高性能代码,因为它完全破坏了复杂性保证.但是,如果你正在修改它,可帮助诊断RBT的问题.这些检查是为了帮助开发人员证明代码是正确的,而不必不断地证明,对正常使用是正确的.