2

我一直是“无例外”阵营的一员，但在宗教上并非如此。我有一个关于使用异常的支持者经常提出的论点的问题。

所以我对 C++ 异常的最大（唯一）抱怨是代码的不可预测性。我希望能够查看代码（在 VIM 中没有任何 IDE）并准确了解它在所有情况下的作用。除了异常，逻辑流程并不明显，因为 throw 和 catch 可以分开许多逻辑层。

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

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

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

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

现在我的问题是：这样做的真正缺点是什么？如果您在我离开很久之后看到此代码并且您正在维护它，您会生气吗？你真的更喜欢 try(s) 和 catch(es) 而不是这种机制，为什么？

4

1 回答 1

1

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

另一方面，每当我看到人们避免异常时，我想他们真的不了解它们的用途。他们总是在谈论 try/catch。实际上，正确编码的异常使用很少尝试/捕获。在我遇到的大多数用例中，异常只是将错误消息传递回堆栈以便它可以退出的一种方式。只有一个 try/catch 块，它在 main 中。

当然，我编写了不会退出的长寿命服务器。他们记录异常传递的消息，将相同的消息返回给客户端，然后继续等待循环。

Bottom line, there should be very few try/catch blocks in your system. Once you understand that, then the logic flow for exception becomes easy to understand. In fact, it's designed into the system.

于 2012-07-19T21:32:48.513 回答