何时抛出异常？

Question

何时抛出异常？我为我的应用程序所不期望的每一个条件创建了异常。UserNameNotValidException, PasswordNotCorrectException等。然而，有人告诉我，我不应该为这些条件设置例外。在我的UML中，这些是主流的异常，那么为什么不应该是异常呢？是否有创建异常的指导或最佳实践？

Answer 1

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

示例1：假设我有一个函数，它应该检查任意类，如果该类继承List<>，则返回true。这个函数提出一个问题：“这个对象是列表的后代吗？”这个函数不应该抛出异常，因为它的操作中没有灰色区域-每个类都继承或不继承List<>，所以答案总是“或”否“。

示例2：假设我有另一个函数，它检查一个列表<>，如果它的长度大于50，返回true；如果长度小于50，则返回false。这个函数会问这样一个问题：“这个列表有50多个项目吗？”但是这个问题做了一个假设-它假设它给出的对象是一个列表。如果我给它一个空，那么这个假设是错误的。在这种情况下，如果函数返回任一千真万确或如果是假的，那么它就违反了自己的规则。函数不能返回什么都行并声称它正确地回答了这个问题。所以它不会返回-它会抛出一个异常。

这与“满载问题”逻辑谬误。每个函数都会问一个问题。如果它所提供的输入使这个问题成为一个谬误，那么抛出一个异常。这一行很难用返回void的函数绘制，但底线是：如果函数对其输入的假设被违反，它应该抛出异常，而不是正常返回。

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

Answer 2

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

Answer 3

我的小指南深受“代码完整”一书的影响：

• 使用异常通知不应忽略的事情。
• 如果错误可以在本地处理，则不要使用异常
• 确保异常处于与其他例程相同的抽象级别。
• 应该为

  真正的例外.