C++异常与错误代理

C++ Exception vs. Error Proxy

本文关键字：代理错误异常 C++ 更新时间：2023-10-16

我一直是"无例外"阵营的一员，但并不虔诚。我对使用例外的支持者经常提出的一个论点有疑问。

因此，我对C++中异常的最大（唯一）抱怨是代码的不可预测性。我希望能够查看代码（在VIM中没有任何IDE），并确切地了解它在所有情况下的作用。除了例外，逻辑流并不明显，因为抛出和捕获可能相隔许多逻辑层。

支持异常响应的典型计数器是："是的，这很糟糕。但嵌套错误代码更糟糕。"

嗯，是的，但这不是的替代方案。

假设你有一个名为MyErrorProxy的类，它有一个虚拟句柄MyXYZError（），如果你知道你的MyClass可能会出现XYZ错误，并且你想在多个逻辑层之外处理它，你就给它传递一个指向MyErrorProxy（它可以是一个mixin、一个接口，或者只是一个集中的错误处理类）的指针？你不想传球吗？好吧，让它成为线程安全的单例。这需要更多的管道，但它是显式的，并且非常容易跟踪逻辑流。

这就是我长期以来的编码方式。

现在我的问题是：这样做的真正缺点是什么？如果你在我离开后很长一段时间看到这个代码，并且你在维护它，你会生气吗？你真的更喜欢尝试和捕捉而不是这种机制吗？为什么？

这不是一个好主意。这听起来像是一种传递错误代码的混乱方式。如果不想使用异常，请使用错误代码。至少有了错误代码，人们就会明白你在做什么。

另一方面，每当我看到人们回避例外时，我想他们真的不理解它们的用途。他们总是在谈论尝试/接球。事实上，正确编码的异常使用很少有尝试/捕获。在我遇到的大多数用例中，异常只是将错误消息传递回堆栈以便退出的一种方式。只有一个试跳/接球盖帽，而且它是主要的。

当然，我已经对不会退出的长寿命服务器进行了编码。它们记录异常传递的消息，向客户端返回相同的消息，然后继续等待循环。

最重要的是，您的系统中应该很少有try/catch块。一旦您理解了这一点，那么异常的逻辑流程就变得很容易理解。事实上，它是在系统中设计的。