我为我的应用程序不期望的每个条件创建了异常。UserNameNotValidException, PasswordNotCorrectException等。
然而，我被告知我不应该为这些条件创造例外。在我的UML中，那些是主要流程的异常，那么为什么它不应该是异常呢?
是否有创建异常的指导或最佳实践?
当前回答
“PasswordNotCorrectException”不是一个使用异常的好例子。用户输入错误的密码是意料之中的，所以在我看来，这几乎不是个例外。您甚至可能从中恢复，显示一个漂亮的错误消息，因此这只是一个有效性检查。
未处理的异常将最终停止执行——这是好事。如果返回false、null或错误代码，则必须自己处理程序的状态。如果您忘记检查某个地方的条件，您的程序可能会继续使用错误的数据运行，并且您可能很难弄清楚发生了什么以及在哪里发生了什么。
当然，空的catch语句也可能导致同样的问题，但至少发现这些语句更容易，而且不需要理解逻辑。
所以根据经验:
在您不想要或无法从错误中恢复的地方使用它们。
其他回答
一般来说，你想要为应用程序中可能发生的任何异常抛出一个"异常"
在您的示例中，这两个异常看起来都是通过密码/用户名验证调用的。在这种情况下，有人会输入错误的用户名/密码并不是什么例外。
它们是UML主要流程的“例外”，但在处理过程中是更多的“分支”。
如果您试图访问您的passwd文件或数据库，但无法访问，这将是一个异常情况，并需要抛出异常。
如果用户名无效或密码不正确，这不是一个例外。这些都是在正常操作流程中应该预料到的事情。异常不属于正常程序操作的一部分，而且相当罕见。
我不喜欢使用异常，因为仅仅通过查看调用就无法判断一个方法是否引发了异常。这就是为什么只有当你不能以一种体面的方式处理这种情况时才应该使用异常(比如“内存不足”或“电脑着火了”)。
安全性与您的示例混为一谈:您不应该告诉攻击者用户名存在，但密码是错误的。这是你不需要分享的额外信息。只要说“用户名或密码不正确”。
抛出异常会导致堆栈unwind，这对性能有一定影响(承认，现代托管环境在这方面有所改进)。仍然在嵌套的情况下反复抛出和捕获异常是一个坏主意。
可能比这更重要的是，例外是针对特殊情况的。它们不应该用于普通的控制流，因为这会损害代码的可读性。
避免抛出异常的主要原因是抛出异常涉及大量开销。
下面这篇文章指出的一件事是，例外是针对异常条件和错误的。
错误的用户名不一定是程序错误，而是用户错误……
下面是关于。net中的异常的一个不错的起点: http://msdn.microsoft.com/en-us/library/ms229030 (VS.80) . aspx
