异常与返回错误代码参数应该是关于流控制的，而不是哲学(错误有多“异常”):

void f1() throws ExceptionType1, ExceptionType2 {}

void catchFunction() {
  try{
    while(someCondition){
      try{
        f1(); 
      }catch(ExceptionType2 e2){
        //do something, don't break the loop
      }
    }
  }catch(ExceptionType1 e1){
    //break the loop, do something else
  }

}

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

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

我想说的是，如果发生了意想不到的行为，应该抛出异常。

比如试图更新或删除一个不存在的实体。它应该在异常可以处理并且有意义的地方被捕获。如果要以另一种方式继续工作，请在Api级别上添加日志记录或返回特定的结果。

如果您期望某些事情是这样的，那么您应该构建代码来检查并确保它是正确的。

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

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.

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

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

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

所以根据经验:

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

最终，决定取决于是使用异常处理更有助于处理此类应用程序级错误，还是通过您自己的机制(如返回状态代码)更有帮助。我不认为哪个更好有一个严格的规则，但我会考虑:

Who's calling your code? Is this a public API of some sort or an internal library? What language are you using? If it's Java, for example, then throwing a (checked) exception puts an explicit burden on your caller to handle this error condition in some way, as opposed to a return status which could be ignored. That could be good or bad. How are other error conditions in the same application handled? Callers won't want to deal with a module that handles errors in an idiosyncratic way unlike anything else in the system. How many things can go wrong with the routine in question, and how would they be handled differently? Consider the difference between a series of catch blocks that handle different errors and a switch on an error code. Do you have structured information about the error you need to return? Throwing an exception gives you a better place to put this information than just returning a status.