一般来说，你想要为应用程序中可能发生的任何异常抛出一个"异常"

在您的示例中，这两个异常看起来都是通过密码/用户名验证调用的。在这种情况下，有人会输入错误的用户名/密码并不是什么例外。

它们是UML主要流程的“例外”，但在处理过程中是更多的“分支”。

如果您试图访问您的passwd文件或数据库，但无法访问，这将是一个异常情况，并需要抛出异常。

避免抛出异常的主要原因是抛出异常涉及大量开销。

下面这篇文章指出的一件事是，例外是针对异常条件和错误的。

错误的用户名不一定是程序错误，而是用户错误……

下面是关于。net中的异常的一个不错的起点: http://msdn.microsoft.com/en-us/library/ms229030 (VS.80) . aspx

一个经验法则是在您通常无法预测的情况下使用异常。例如数据库连接、磁盘上丢失的文件等。对于您可以预测的场景，例如用户试图使用错误的密码登录，您应该使用返回布尔值的函数，并知道如何优雅地处理这种情况。您不希望仅仅因为有人输入了密码错误而抛出异常，从而突然结束执行。

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.

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

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

To my mind, the fundamental question should be whether one would expect that the caller would want to continue normal program flow if a condition occurs. If you don't know, either have separate doSomething and trySomething methods, where the former returns an error and the latter does not, or have a routine that accepts a parameter to indicate whether an exception should be thrown if it fails). Consider a class to send commands to a remote system and report responses. Certain commands (e.g. restart) will cause the remote system to send a response but then be non-responsive for a certain length of time. It is thus useful to be able to send a "ping" command and find out whether the remote system responds in a reasonable length of time without having to throw an exception if it doesn't (the caller would probably expect that the first few "ping" attempts would fail, but one would eventually work). On the other hand, if one has a sequence of commands like:

  exchange_command("open tempfile");
  exchange_command("write tempfile data {whatever}");
  exchange_command("write tempfile data {whatever}");
  exchange_command("write tempfile data {whatever}");
  exchange_command("write tempfile data {whatever}");
  exchange_command("close tempfile");
  exchange_command("copy tempfile to realfile");

人们会希望任何操作的失败都能中止整个序列。虽然可以检查每个操作以确保操作成功，但如果命令失败，让exchange_command()例程抛出异常会更有帮助。

实际上，在上面的场景中，有一个参数来选择一些失败处理模式可能会有所帮助:从不抛出异常，仅为通信错误抛出异常，或者在命令没有返回“成功”指示的任何情况下抛出异常。