为什么异常处理不好？ [关闭]

Google 的 Go 语言没有例外作为设计选择，而 Linux 名人 Linus 则称例外为垃圾。为什么？

异常使编写代码变得非常容易，其中抛出的异常将破坏不变量并使对象处于不一致的状态。它们本质上迫使您记住，您所做的大多数语句都可能会抛出错误，并正确处理它。这样做可能很棘手并且违反直觉。

考虑这样一个简单的例子：

class Frobber
{
    int m_NumberOfFrobs;
    FrobManager m_FrobManager;

public:
    void Frob()
    {
        m_NumberOfFrobs++;

        m_FrobManager.HandleFrob(new FrobObject());
    }
};

假设FrobManager will delete the FrobObject，这看起来不错，对吧？或者也许不是……想象一下，如果FrobManager::HandleFrob() or operator new抛出异常。在这个例子中，增量为m_NumberOfFrobs不会被回滚。因此，任何使用此实例的人Frobber将有一个可能损坏的对象。

这个例子可能看起来很愚蠢（好吧，我不得不花点力气来构造一个:-)），但是，要点是，如果程序员没有不断地考虑异常，并确保状态的每个排列都得到滚动每当有投掷的时候，你都会遇到麻烦。

例如，您可以像考虑互斥体一样来考虑它。在关键部分内，您依靠多个语句来确保数据结构未损坏并且其他线程无法看到您的中间值。如果这些语句中的任何一个没有随机运行，那么您最终会陷入痛苦的世界。现在去掉锁和并发，并像这样思考每个方法。如果愿意的话，可以将每个方法视为对象状态的排列事务。在方法调用开始时，对象应该处于干净状态，并且在结束时也应该处于干净状态。其间，变量foo可能不符合bar，但你的代码最终会纠正这个问题。例外意味着你的任何一个陈述都可以随时打断你。在每个单独的方法中，您有责任确保其正确并在发生这种情况时回滚，或者对您的操作进行排序，以便抛出不会影响对象状态。如果你弄错了（而且很容易犯这种错误），那么调用者最终会看到你的中间值。

像 RAII 这样的方法（C++ 程序员喜欢将其称为此问题的最终解决方案）对于防止此问题大有帮助。但它们并不是灵丹妙药。它将确保您在抛出时释放资源，但不会让您不必考虑对象状态的损坏和调用者看到中间值。因此，对于很多人来说，根据编码风格，更容易说，没有例外。如果限制所编写的代码类型，就更难引入这些错误。如果不这样做，就很容易犯错误。

整本书都是关于 C++ 中的异常安全编码的。很多专家都搞错了。如果它真的那么复杂并且有那么多细微差别，也许这是一个好兆头，表明您需要忽略该功能。 :-)