我想说的是，如果发生了意想不到的行为，应该抛出异常。

比如试图更新或删除一个不存在的实体。它应该在异常可以处理并且有意义的地方被捕获。如果要以另一种方式继续工作，请在Api级别上添加日志记录或返回特定的结果。

如果您期望某些事情是这样的，那么您应该构建代码来检查并确保它是正确的。

异常是一种代价高昂的效果，例如，如果您有一个用户提供了无效的密码，那么通常更好的方法是返回一个失败标志，或其他一些无效的指示。

这是由于异常处理的方式，真正的错误输入和唯一的关键停止项应该是异常，而不是失败的登录信息。

我个人的指导方针是:当发现当前代码块的基本假设为假时抛出异常。

例1:假设我有一个函数，它应该检查任意类，如果该类继承自List<>，则返回true。这个函数问一个问题:“这个对象是List的后代吗?”这个函数永远不会抛出异常，因为它的操作中没有灰色地带——每个单独的类要么继承了List<>，要么继承了List<>，所以答案总是“是”或“否”。

Example 2: say I have another function which examines a List<> and returns true if its length is more than 50, and false if the length is less. This function asks the question, "Does this list have more than 50 items?" But this question makes an assumption - it assumes that the object it is given is a list. If I hand it a NULL, then that assumption is false. In that case, if the function returns either true or false, then it is breaking its own rules. The function cannot return anything and claim that it answered the question correctly. So it doesn't return - it throws an exception.

这与“负载问题”逻辑谬误相当。每个函数都问一个问题。如果给出的输入使该问题成为谬误，则抛出异常。对于返回void的函数，这条线很难画出来，但底线是:如果函数对其输入的假设违反了，它应该抛出异常，而不是正常返回。

这个等式的另一方面是:如果你发现你的函数经常抛出异常，那么你可能需要改进它们的假设。

我认为只有在无法摆脱当前状态时才应该抛出异常。例如，如果您正在分配内存，但没有任何内存可以分配。在您提到的情况下，您可以清楚地从这些状态中恢复，并相应地将错误代码返回给调用者。

You will see plenty of advice, including in answers to this question, that you should throw exceptions only in "exceptional" circumstances. That seems superficially reasonable, but is flawed advice, because it replaces one question ("when should I throw an exception") with another subjective question ("what is exceptional"). Instead, follow the advice of Herb Sutter (for C++, available in the Dr Dobbs article When and How to Use Exceptions, and also in his book with Andrei Alexandrescu, C++ Coding Standards): throw an exception if, and only if

没有满足先决条件(通常会出现以下情况之一 不可能的)或 替代方案将无法满足后置条件或 替代方案将无法保持不变式。

为什么这样更好呢?它不是用几个关于前置条件，后置条件和不变量的问题代替了这个问题吗?这是更好的几个相关的原因。

Preconditions, postconditions and invariants are design characteristics of our program (its internal API), whereas the decision to throw is an implementation detail. It forces us to bear in mind that we must consider the design and its implementation separately, and our job while implementing a method is to produce something that satisfies the design constraints. It forces us to think in terms of preconditions, postconditions and invariants, which are the only assumptions that callers of our method should make, and are expressed precisely, enabling loose coupling between the components of our program. That loose coupling then allows us to refactor the implementation, if necessary. The post-conditions and invariants are testable; it results in code that can be easily unit tested, because the post-conditions are predicates our unit-test code can check (assert). Thinking in terms of post-conditions naturally produces a design that has success as a post-condition, which is the natural style for using exceptions. The normal ("happy") execution path of your program is laid out linearly, with all the error handling code moved to the catch clauses.

首先，如果API的用户对特定的、细粒度的故障不感兴趣，那么为他们设置特定的异常就没有任何价值。

由于通常不可能知道什么可能对用户有用，一个更好的方法是有特定的异常，但确保它们继承自一个公共类(例如，std::exception或其在c++中的派生类)。这允许您的客户端捕获特定的异常(如果他们愿意的话)，或者捕获更一般的异常(如果他们不关心的话)。

因为它们是正常发生的事情。异常不是控制流机制。用户经常会输入错误的密码，这不是特例。异常应该是一个真正罕见的事情，UserHasDiedAtKeyboard类型的情况。