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

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

我有三种情况。

Bad or missing input should not be an exception. Use both client side js and server side regex to detect, set attributes and forward back to the same page with messages. The AppException. This is usually an exception that you detect and throw with in your code. In other words these are ones you expect (the file does not exist). Log it, set the message, and forward back to the general error page. This page usually has a bit of info about what happened. The unexpected Exception. These are the ones you don't know about. Log it with details and forward them to a general error page.

希望这能有所帮助

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

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
  }

}

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

我认为只有在无法摆脱当前状态时才应该抛出异常。例如，如果您正在分配内存，但没有任何内存可以分配。在您提到的情况下，您可以清楚地从这些状态中恢复，并相应地将错误代码返回给调用者。

You will see plenty of advice, including in answers to this question, that you should throw exceptions only in "exceptional" circumstances. That seems superficially reasonable, but is flawed advice, because it replaces one question ("when should I throw an exception") with another subjective question ("what is exceptional"). Instead, follow the advice of Herb Sutter (for C++, available in the Dr Dobbs article When and How to Use Exceptions, and also in his book with Andrei Alexandrescu, C++ Coding Standards): throw an exception if, and only if

没有满足先决条件(通常会出现以下情况之一 不可能的)或 替代方案将无法满足后置条件或 替代方案将无法保持不变式。

为什么这样更好呢?它不是用几个关于前置条件，后置条件和不变量的问题代替了这个问题吗?这是更好的几个相关的原因。

Preconditions, postconditions and invariants are design characteristics of our program (its internal API), whereas the decision to throw is an implementation detail. It forces us to bear in mind that we must consider the design and its implementation separately, and our job while implementing a method is to produce something that satisfies the design constraints. It forces us to think in terms of preconditions, postconditions and invariants, which are the only assumptions that callers of our method should make, and are expressed precisely, enabling loose coupling between the components of our program. That loose coupling then allows us to refactor the implementation, if necessary. The post-conditions and invariants are testable; it results in code that can be easily unit tested, because the post-conditions are predicates our unit-test code can check (assert). Thinking in terms of post-conditions naturally produces a design that has success as a post-condition, which is the natural style for using exceptions. The normal ("happy") execution path of your program is laid out linearly, with all the error handling code moved to the catch clauses.

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

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