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

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

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

所以根据经验:

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

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

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.

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

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
  }

}

我想说，对于什么时候使用异常并没有硬性规定。然而，使用或不使用它们有很好的理由:

使用异常的原因:

The code flow for the common case is clearer Can return complex error information as an object (although this can also be achieved using error "out" parameter passed by reference) Languages generally provide some facility for managing tidy cleanup in the event of the exception (try/finally in Java, using in C#, RAII in C++) In the event no exception is thrown, execution can sometimes be faster than checking return codes In Java, checked exceptions must be declared or caught (although this can be a reason against)

不使用异常的原因:

Sometimes it's overkill if the error handling is simple If exceptions are not documented or declared, they may be uncaught by calling code, which may be worse than if the the calling code just ignored a return code (application exit vs silent failure - which is worse may depend on the scenario) In C++, code that uses exceptions must be exception safe (even if you don't throw or catch them, but call a throwing function indirectly) In C++, it is hard to tell when a function might throw, therefore you must be paranoid about exception safety if you use them Throwing and catching exceptions is generally significantly more expensive compared to checking a return flag

一般来说，我更倾向于在Java中使用异常，而不是在c++或c#中，因为我认为异常，无论是否声明，都是函数正式接口的基本组成部分，因为更改异常保证可能会破坏调用代码。在Java IMO中使用它们的最大优势是，您知道调用者必须处理异常，这提高了正确行为的机会。

正因为如此，在任何语言中，我总是从一个公共类派生一层代码或API中的所有异常，这样调用的代码就总能保证捕获所有异常。另外，我认为在编写API或库时抛出特定于实现的异常类是不好的(即从较低的层包装异常，以便调用者接收到的异常在您的接口上下文中是可以理解的)。

注意，Java区分了一般异常和运行时异常，因为后者不需要声明。我只会使用运行时异常类，当您知道错误是由程序中的错误导致的。

我有三种情况。

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.

希望这能有所帮助

如果用户名无效或密码不正确，这不是一个例外。这些都是在正常操作流程中应该预料到的事情。异常不属于正常程序操作的一部分，而且相当罕见。

我不喜欢使用异常，因为仅仅通过查看调用就无法判断一个方法是否引发了异常。这就是为什么只有当你不能以一种体面的方式处理这种情况时才应该使用异常(比如“内存不足”或“电脑着火了”)。