我参加了“无例外”阵营，但并非如此。我对使用例外的支持者经常提出的论点有疑问。
因此，我对C ++异常的最大（唯一）抱怨是代码的不可预测性。我希望能够查看代码（在VIM中没有任何IDE）并确切地看到它在所有情况下的作用。除了异常之外，逻辑流程并不明显，因为throw和catch可以分开许多逻辑层。
支持异常响应的典型计数器是：“是的，这太糟糕了。但是嵌套的错误代码会更多。”
嗯，是的，但是不是替代方案。
假设您有一个名为MyErrorProxy的类，其中包含一个虚拟的handleMyXYZError（），如果您知道您的MyClass可能会出现XYZ错误，并且您想要处理许多逻辑层，那么您将向它传递一个指向MyErrorProxy的指针（可以是一个混合，一个接口，还是只是一个集中的错误处理类）？你不想传递指针？很好，使它成为一个线程安全的单身人士。这需要更多的管道，但它是显式的并且非常容易跟踪逻辑流程。
这就是我长时间编码的方式。
现在我的问题是：这样做的真正缺点是什么？如果你在我离开后很长时间看到这段代码并且你正在维护它，你会生气吗？你真的宁愿选择try（s）和catch（es）而不是这种机制吗？为什么？
答案 0 :(得分：1)
这不是一个好主意。这听起来像是一种传递错误代码的混乱方式。如果您不想使用异常，请使用错误代码。至少对于错误代码，人们会理解你在做什么。
另一方面，每当我看到人们避免异常时，我想他们真的不明白他们的用法。他们总是谈论尝试/捕获。实际上，正确编码的异常使用几乎没有尝试/捕获。在我遇到的大多数用例中，异常只是一种将错误消息传递回堆栈以便退出的方法。只有一个try / catch块，它位于main。
当然，我已经编写了不会退出的长寿命服务器。它们记录异常传递的消息，将相同的消息返回给客户端，并继续等待它们。
最重要的是，系统中应该有很少的try / catch块。一旦理解了这一点，那么异常的逻辑流程就变得易于理解。事实上，它已被设计到系统中。