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

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

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

所以根据经验:

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

异常是一种代价高昂的效果，例如，如果您有一个用户提供了无效的密码，那么通常更好的方法是返回一个失败标志，或其他一些无效的指示。

这是由于异常处理的方式，真正的错误输入和唯一的关键停止项应该是异常，而不是失败的登录信息。

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()例程抛出异常会更有帮助。

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

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

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

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

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

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

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

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

所以根据经验:

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

以下是我的建议:

我不认为这总是一个抛出异常的好方法，因为它将花费更多的时间和内存来处理这样的异常。

在我看来，如果某些事情可以用“友好、礼貌”的方式处理(这意味着如果我们可以“通过使用if......或类似的东西来预测这样的错误)，我们应该避免使用“异常”，而只是返回一个像“false”这样的标志，用一个外部参数值告诉他/她详细的原因。

举个例子，我们可以这样创建一个类:

public class ValueReturnWithInfo<T>
{
   public T Value{get;private set;}
   public string errorMsg{get;private set;}
   public ValueReturnWithInfo(T value,string errmsg)
   {
      Value = value;
      errMsg = errmsg;
   }
}

我们可以使用这种“多值返回”类来代替错误，这似乎是处理异常问题的一种更好、更礼貌的方式。

但是，请注意，如果一些错误不能如此容易地用"if"......(例如FileIO异常)描述(这取决于您的编程经验)，则必须抛出异常。