我使用的规则是:永远不要使用未经检查的异常!(或者当你看不到任何方法的时候)

从使用您的库的开发人员或使用您的库/应用程序的最终用户的角度来看，遇到由于不应出现的异常而导致应用程序崩溃的情况真的很糟糕。指望包罗万象也不行。

通过这种方式，最终用户仍然可以看到错误消息，而不是应用程序完全消失。

你是正确的。

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

例如:

/**
 * @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)将出现。

来自Java学习者:

When an exception occurs, you have to either catch and handle the exception, or tell compiler that you can't handle it by declaring that your method throws that exception, then the code that uses your method will have to handle that exception (even it also may choose to declare that it throws the exception if it can't handle it). Compiler will check that we have done one of the two things (catch, or declare). So these are called Checked exceptions. But Errors, and Runtime Exceptions are not checked for by compiler (even though you can choose to catch, or declare, it is not required). So, these two are called Unchecked exceptions. Errors are used to represent those conditions which occur outside the application, such as crash of the system. Runtime exceptions are usually occur by fault in the application logic. You can't do anything in these situations. When runtime exception occur, you have to re-write your program code. So, these are not checked by compiler. These runtime exceptions will uncover in development, and testing period. Then we have to refactor our code to remove these errors.

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

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

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

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

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

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

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

我认为我们可以从以下几个问题来考虑例外:

为什么会发生异常?当它发生时我们能做什么

一个错误，一个bug。如方法调用空对象。

String name = null;
... // some logics
System.out.print(name.length()); // name is still null here

这种异常应该在测试期间修复。否则，它会破坏生产，你会得到一个非常严重的bug，需要立即修复。这种异常不需要检查。

通过来自外部的输入，您不能控制或信任外部服务的输出。

String name = ExternalService.getName(); // return null
System.out.print(name.length());    // name is null here

在这里，如果您希望在名称为空时继续，则可能需要检查名称是否为空，否则，您可以让它单独运行，它将在这里停止并向调用者提供运行时异常。 这种异常不需要检查。

通过来自外部的运行时异常，您不能控制或信任外部服务。

在这里，如果您希望在发生异常时继续执行，则可能需要从ExternalService捕获所有异常，否则，您可以不去管它，它将在这里停止并向调用者提供运行时异常。

通过来自外部的受控异常，您不能控制或信任外部服务。

在这里，如果您希望在发生异常时继续执行，则可能需要从ExternalService捕获所有异常，否则，您可以不去管它，它将在这里停止并向调用者提供运行时异常。

在这种情况下，我们需要知道ExternalService中发生了什么样的异常吗?这取决于:

如果您可以处理某些类型的异常，则需要捕获它们并进行处理。对其他人来说，泡一下。 如果您需要记录或响应用户特定的异常，您可以捕获它们。对其他人来说，泡一下。