错误处理注意事项
问题： 长期以来，我对这种exceptions机制感到担心，因为我觉得它并不能真正解决应有的问题。 要求：关于该主题的争论很长时间，而且大多数人都在努力比较exceptions和返回错误代码。这绝对不是这里的主题。 尝试定义错误，我同意Bjarne Stroustrup和Herb Sutter的CppCoreGuidelines 错误表示该功能无法实现其广告目的 要求：该exception机制是用于处理错误的语言语义。 要求：对我来说，没有“没有借口”的功能不能完成任务：要么我们错误地定义了前后条件，所以该功能无法确保结果，或者某些特殊情况对于花时间在开发上没有足够重要的意义。一个办法。考虑到IMO，常规代码和错误代码处理之间的区别（在实施之前）是非常主观的。 要求：使用异常指示何时不保留前置条件或后置条件是该exception机制的另一个目的，主要是用于调试目的。我的目标不是这里的用法exceptions。 在许多书籍，教程和其他资料中，它们倾向于将错误处理显示为一门相当客观的科学，可以解决这一问题，exceptions而您只需要catch它们具有强大的软件就可以从任何情况下恢复。但是，作为开发人员的几年时间使我从另一种方法来看问题： 程序员倾向于通过抛出异常来简化他们的任务，而这种特殊情况似乎太少而无法仔细实现。典型的情况是：内存不足问题，磁盘已满问题，文件损坏等，这可能就足够了，但并不总是从体系结构级别决定。 程序员往往不会仔细阅读有关库中异常的文档，并且通常不知道函数何时何地抛出。而且，即使他们知道了，他们也并没有真正管理它们。 程序员往往没有足够早地捕获异常，当他们捕获异常时，主要是记录并抛出更多异常。（请参阅第一点）。 这有两个结果： 经常发生的错误可以在开发的早期发现并进行调试（很好）。 罕见的异常无法管理，并且会使系统在用户家崩溃（带有一条漂亮的日志消息）。有时会报告错误，甚至不会报告。 考虑到这一点，海事组织错误机制的主要目的应该是： 在不管理某些特定情况的代码中使可见。 发生这种情况时，将问题运行时与相关代码（至少是调用方）进行通信。 提供恢复机制 exception语义作为错误处理机制的主要缺陷是IMO：很容易看到a throw在源代码中的位置，但是绝对不明显，通过查看声明来知道特定功能是否会抛出。这带来了我上面介绍的所有问题。 该语言不会像对语言的其他方面（例如强类型的变量）那样严格执行和检查错误代码 尝试解决方案 为了改善这一点，我开发了一个非常简单的错误处理系统，该系统试图使错误处理的重要性与普通代码相同。 这个想法是： 每个（相关）功能都接收到对success非常轻的对象的引用，并可能将其设置为错误状态。在保存文本错误之前，该对象非常轻。 如果提供的对象已经包含错误，则鼓励函数跳过其任务。 绝对不能覆盖错误。 完整的设计显然会全面考虑每个方面（约10页），以及如何将其应用于OOP。 Success该类的示例： class Success { public: enum SuccessStatus { ok = 0, // All is fine error = 1, // …