我为我的应用程序不期望的每个条件创建了异常。UserNameNotValidException, PasswordNotCorrectException等。
然而，我被告知我不应该为这些条件创造例外。在我的UML中，那些是主要流程的异常，那么为什么它不应该是异常呢?
是否有创建异常的指导或最佳实践?
当前回答
一般来说，你想要为应用程序中可能发生的任何异常抛出一个"异常"
在您的示例中，这两个异常看起来都是通过密码/用户名验证调用的。在这种情况下，有人会输入错误的用户名/密码并不是什么例外。
它们是UML主要流程的“例外”，但在处理过程中是更多的“分支”。
如果您试图访问您的passwd文件或数据库，但无法访问，这将是一个异常情况，并需要抛出异常。
其他回答
我有三种情况。
Bad or missing input should not be an exception. Use both client side js and server side regex to detect, set attributes and forward back to the same page with messages. The AppException. This is usually an exception that you detect and throw with in your code. In other words these are ones you expect (the file does not exist). Log it, set the message, and forward back to the general error page. This page usually has a bit of info about what happened. The unexpected Exception. These are the ones you don't know about. Log it with details and forward them to a general error page.
希望这能有所帮助
“PasswordNotCorrectException”不是一个使用异常的好例子。用户输入错误的密码是意料之中的，所以在我看来，这几乎不是个例外。您甚至可能从中恢复，显示一个漂亮的错误消息，因此这只是一个有效性检查。
未处理的异常将最终停止执行——这是好事。如果返回false、null或错误代码，则必须自己处理程序的状态。如果您忘记检查某个地方的条件，您的程序可能会继续使用错误的数据运行，并且您可能很难弄清楚发生了什么以及在哪里发生了什么。
当然，空的catch语句也可能导致同样的问题，但至少发现这些语句更容易，而且不需要理解逻辑。
所以根据经验:
在您不想要或无法从错误中恢复的地方使用它们。
异常是一种代价高昂的效果，例如，如果您有一个用户提供了无效的密码，那么通常更好的方法是返回一个失败标志，或其他一些无效的指示。
这是由于异常处理的方式，真正的错误输入和唯一的关键停止项应该是异常，而不是失败的登录信息。
一般来说，你想要为应用程序中可能发生的任何异常抛出一个"异常"
在您的示例中，这两个异常看起来都是通过密码/用户名验证调用的。在这种情况下，有人会输入错误的用户名/密码并不是什么例外。
它们是UML主要流程的“例外”，但在处理过程中是更多的“分支”。
如果您试图访问您的passwd文件或数据库，但无法访问，这将是一个异常情况，并需要抛出异常。
异常类就像“正常”类。当一个新类“是”一个不同类型的对象，具有不同的字段和不同的操作时，您可以创建一个新类。
As a rule of thumb, you should try balance between the number of exceptions and the granularity of the exceptions. If your method throws more than 4-5 different exceptions, you can probably merge some of them into more "general" exceptions, (e.g. in your case "AuthenticationFailedException"), and using the exception message to detail what went wrong. Unless your code handles each of them differently, you needn't creates many exception classes. And if it does, may you should just return an enum with the error that occured. It's a bit cleaner this way.
