何时抛出异常？
我有我的应用程序不期望的每个条件创建的例外。 UserNameNotValidException ， PasswordNotCorrectException等
不过，有人告诉我，我不应该为这些情况创建例外。 在我的UML中，这些都是主流的例外，那为什么它不是一个例外呢？
任何创建异常的指导或最佳实践？
我个人的指导方针是：当发现当前代码块的基本假设是错误时抛出异常。
示例1：假设我有一个函数应该检查一个任意类，如果该类继承自List <>，则返回true。 这个函数提出这个问题：“这个对象是List的后裔吗？” 这个函数不应该抛出一个异常，因为它的操作中没有灰色区域 - 每一个类不是从List <>继承，所以答案总是“是”或“否”。
例2：假设我有另一个检查List <>的函数，如果它的长度大于50则返回true，如果长度小于则返回false。 这个功能提出这个问题，“这个清单是否有超过50个项目？” 但是这个问题做了一个假设 - 它假定它给出的对象是一个列表。 如果我把它交给NULL，那么这个假设是错误的。 在这种情况下，如果函数返回true或false，那么它就违反了它自己的规则。 该函数不能返回任何东西，并声称它正确地回答了问题。 所以它不会返回 - 它会抛出一个异常。
这与“加载问题”的逻辑谬误是可比的。 每个功能都会提出一个问题。 如果它给出的输入使得这个问题成为一个谬论，那么抛出一个异常。 这条线很难用返回void的函数绘制，但底线是：如果函数关于其输入的假设被违反，它应该抛出异常而不是正常返回。
这个等式的另一方面是：如果你发现你的函数经常抛出异常，那么你可能需要改进他们的假设。
因为他们是会正常发生的事情。 例外不是控制流程机制。 用户经常会输错密码，这不是一个特例。 例外应该是一个真正罕见的事情， UserHasDiedAtKeyboard类型的情况。
我的小指南深受伟大书籍“完整代码”的影响：
上一篇: When to throw an exception?
下一篇: builder.parse((new StringReader(xml)) returns DeferredDocumentImpl