我的小指南很大程度上受到了“代码完成”这本伟大的书的影响:

使用异常来通知不应该被忽略的事情。 如果错误可以在本地处理，就不要使用异常 确保异常与例程的其余部分处于相同的抽象级别。 异常应该留给真正的异常。

抛出异常的经验法则非常简单。当你的代码进入UNRECOVERABLE INVALID状态时，你可以这样做。如果数据被泄露，或者您无法回溯到目前为止发生的处理，那么您必须终止它。你还能做什么呢?您的处理逻辑最终将在其他地方失败。如果你能以某种方式恢复，那么就这样做，不要抛出异常。

在你的特定情况下，如果你被迫做一些愚蠢的事情，比如接受提款，然后才检查用户/密码，你应该通过抛出一个异常来终止这个过程，通知发生了一些不好的事情，并防止进一步的损害。

for me Exception should be thrown when a required technical or business rule fails. for instance if a car entity is associated with array of 4 tires ... if one tire or more are null ... an exception should be Fired "NotEnoughTiresException" , cuz it can be caught at different level of the system and have a significant meaning through logging. besides if we just try to flow control the null and prevent the instanciation of the car . we might never never find the source of the problem , cuz the tire isn't supposed to be null in the first place .

异常类就像“正常”类。当一个新类“是”一个不同类型的对象，具有不同的字段和不同的操作时，您可以创建一个新类。

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.

If it's code running inside a loop that will likely cause an exception over and over again, then throwing exceptions is not a good thing, because they are pretty slow for large N. But there is nothing wrong with throwing custom exceptions if the performance is not an issue. Just make sure that you have a base exception that they all inherite, called BaseException or something like that. BaseException inherits System.Exception, but all of your exceptions inherit BaseException. You can even have a tree of Exception types to group similar types, but this may or may not be overkill.

因此，简短的回答是，如果它不会导致显著的性能损失(除非抛出大量异常，否则不应该如此)，那么就继续执行。

“PasswordNotCorrectException”不是一个使用异常的好例子。用户输入错误的密码是意料之中的，所以在我看来，这几乎不是个例外。您甚至可能从中恢复，显示一个漂亮的错误消息，因此这只是一个有效性检查。

未处理的异常将最终停止执行——这是好事。如果返回false、null或错误代码，则必须自己处理程序的状态。如果您忘记检查某个地方的条件，您的程序可能会继续使用错误的数据运行，并且您可能很难弄清楚发生了什么以及在哪里发生了什么。

当然，空的catch语句也可能导致同样的问题，但至少发现这些语句更容易，而且不需要理解逻辑。

所以根据经验:

在您不想要或无法从错误中恢复的地方使用它们。