抛出异常会导致堆栈unwind，这对性能有一定影响(承认，现代托管环境在这方面有所改进)。仍然在嵌套的情况下反复抛出和捕获异常是一个坏主意。

可能比这更重要的是，例外是针对特殊情况的。它们不应该用于普通的控制流，因为这会损害代码的可读性。

主要有两类异常:

1)系统异常(如数据库连接丢失)或 2)用户异常。(例如用户输入验证，“密码不正确”)

我发现创建自己的用户异常类很有帮助，当我想抛出一个用户错误时，我想要以不同的方式处理(即资源错误显示给用户)，然后我在我的主错误处理程序中所需要做的就是检查对象类型:

            If TypeName(ex) = "UserException" Then
               Display(ex.message)
            Else
               DisplayError("An unexpected error has occured, contact your help  desk")                   
               LogError(ex)
            End If

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

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

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

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.

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

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

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

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

You may use a little bit generic exceptions for that conditions. For e.g. ArgumentException is meant to be used when anything goes wrong with the parameters to a method (with the exception of ArgumentNullException). Generally you would not need exceptions like LessThanZeroException, NotPrimeNumberException etc. Think of the user of your method. The number of the conditions that she will want to handle specifically is equal to the number of the type of the exceptions that your method needs to throw. This way, you can determine how detailed exceptions you will have.

顺便说一下，总是尝试为库的用户提供一些避免异常的方法。TryParse就是一个很好的例子，它的存在使你不必使用int。解析并捕获异常。在您的情况下，您可能希望提供一些方法来检查用户名是否有效或密码是否正确，这样您的用户(或您)就不必进行大量异常处理。这将有望产生更易于阅读的代码和更好的性能。