这不仅仅是从异常中恢复的能力问题。在我看来，最重要的是调用者是否对捕获异常感兴趣。

如果您编写的库用于其他地方，或应用程序中的较低级别层，请询问自己调用者是否有兴趣捕获(了解)您的异常。如果他不是，那么使用一个未检查的异常，这样就不会给他带来不必要的负担。

这是许多框架使用的哲学。尤其是Spring和hibernate——它们精确地将已知的受控异常转换为未检查异常，因为Java中过度使用了受控异常。我能想到的一个例子是来自json.org的JSONException，这是一个受检查的异常，最烦人的是——它应该是不受检查的，但开发人员根本没有考虑到这一点。

顺便说一下，大多数情况下，调用者对异常的兴趣与从异常中恢复的能力直接相关，但情况并非总是如此。

在任何一个足够大的系统上，有很多层，检查异常是无用的，因为无论如何，您需要一个架构级策略来处理异常将如何处理(使用故障屏障)。

使用受控异常，您的错误处理策略是微管理的，在任何大型系统上都无法承受。

大多数情况下，您不知道错误是否“可恢复”，因为您不知道API的调用者位于哪一层。

假设我创建了一个StringToInt API，用于将整数的字符串表示形式转换为Int。如果API是用“foo”字符串调用的，我必须抛出检查异常吗?它可以恢复吗?我不知道，因为在他的层中，我的StringToInt API的调用者可能已经验证了输入，如果抛出这个异常，它要么是一个错误，要么是一个数据损坏，它是不可恢复的这一层。

在这种情况下，API的调用者不想捕获异常。他只想让异常“冒出来”。如果我选择了一个受控异常，这个调用者将有大量无用的catch块，只能人为地重新抛出异常。

大多数时候，什么是可恢复的取决于API的调用者，而不是API的编写者。API不应该使用受控异常，因为只有未受控异常才允许选择捕获或忽略异常。

You can call it a checked or unchecked exception; however, both types of exception can be caught by the programmer, so the best answer is: write all of your exceptions as unchecked and document them. That way the developer who uses your API can choose whether he or she wants to catch that exception and do something. Checked exceptions are a complete waste of everyone's time and it makes your code a shocking nightmare to look at. Proper unit testing will then bring up any exceptions that you may have to catch and do something with.

你是正确的。

未经检查的异常用于让系统快速失效，这是一件好事。为了正常工作，你应该清楚地说明你的方法期望什么。通过这种方式，您可以只验证输入一次。

例如:

/**
 * @params operation - The operation to execute.
 * @throws IllegalArgumentException if the operation is "exit"
 */
 public final void execute( String operation ) {
     if( "exit".equals(operation)){
          throw new IllegalArgumentException("I told you not to...");
     }
     this.operation = operation; 
     .....  
 }
 private void secretCode(){
      // we perform the operation.
      // at this point the opreation was validated already.
      // so we don't worry that operation is "exit"
      .....  
 }

举个例子。关键是，如果系统快速失效，那么你就会知道它在哪里以及为什么会失效。你会得到这样的堆栈跟踪:

 IllegalArgumentException: I told you not to use "exit" 
 at some.package.AClass.execute(Aclass.java:5)
 at otherPackage.Otherlass.delegateTheWork(OtherClass.java:4569)
 ar ......

你会知道发生了什么。“delegateTheWork”方法中的OtherClass(在第4569行)使用“exit”值调用你的类，即使它不应该这样做等等。

否则你将不得不在你的代码中散布验证，这很容易出错。另外，有时很难跟踪哪里出了问题，可能会有几个小时令人沮丧的调试

同样的事情也发生在nullpointerexception中。如果你有一个700行的类，有15个方法，使用30个属性，它们都不能为空，而不是在每个方法中验证可为空性，你可以使所有这些属性都是只读的，并在构造函数或工厂方法中验证它们。

 public static MyClass createInstane( Object data1, Object data2 /* etc */ ){ 
      if( data1 == null ){ throw NullPointerException( "data1 cannot be null"); }

  }


  // the rest of the methods don't validate data1 anymore.
  public void method1(){ // don't worry, nothing is null 
      ....
  }
  public void method2(){ // don't worry, nothing is null 
      ....
  }
  public void method3(){ // don't worry, nothing is null 
      ....
  }

当程序员(你或你的同事)做的每件事都是正确的，验证输入，运行测试，所有的代码都是完美的，但代码连接到第三方web服务可能会关闭(或你正在使用的文件被另一个外部进程删除等)时，检查异常是有用的。web服务甚至可以在连接尝试之前进行验证，但是在数据传输过程中出错了。

在这种情况下，你或你的同事都无能为力。但你还是得做点什么，不能让应用程序在用户眼中消失。你使用一个检查异常来处理异常，当发生这种情况时你能做什么?，大多数时候，只是尝试记录错误，可能会保存你的工作(应用程序工作)，并向用户显示消息。(网站blabla宕机，请稍后重试)

如果检查过的异常被过度使用(通过在所有方法签名中添加“throw exception”)，那么您的代码将变得非常脆弱，因为每个人都会忽略这个异常(因为太普遍)，代码质量将严重受损。

如果过度使用未检查异常，也会发生类似的情况。这段代码的用户不知道是否会出现错误，因此进行了大量的尝试{…}catch(Throwable t)将出现。

我们必须根据是否是程序员错误来区分这两种类型的异常。

If an error is a programmer error, it must be an Unchecked Exception. For example: SQLException/IOException/NullPointerException. These exceptions are programming errors. They should be handled by programmer. While in JDBC API, SQLException is Checked Exception, In Spring JDBCTemplate it is an Unchecked Exception.Programmer doesn't worry about SqlException, when use Spring. If an error is not a programmer error and the reason is coming from external, it must be a Checked Exception. For example: if the file is deleted or file permission is changed by someone else, It should be recovered.

FileNotFoundException是理解细微差别的好例子。在找不到文件的情况下抛出FileNotFoundException。这种例外有两个原因。如果文件路径是由开发人员定义的或通过GUI从最终用户获取的，那么它应该是一个未检查的异常。如果文件被其他人删除，它应该是一个Checked Exception。

检查异常可以用两种方式处理。它们使用try-catch或传播异常。在异常传播的情况下，由于异常处理，调用堆栈中的所有方法都将紧密耦合。这就是为什么我们必须小心地使用已检查异常。

如果您开发了一个分层的企业系统，您必须选择大多数未检查的异常来抛出，但不要忘记在您什么都做不了的情况下使用已检查的异常。

我认为当声明应用程序异常时，它应该是未检查的异常，即RuntimeException的子类。 原因是它不会用try-catch和方法上的抛出声明使应用程序代码混乱。如果你的应用程序使用Java Api，抛出检查异常，无论如何都需要处理。对于其他情况，应用程序可以抛出未经检查的异常。如果应用程序调用方仍然需要处理未检查的异常，则可以这样做。