你是正确的。

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

例如:

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

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

有一种情况正好相反:永远不要使用受控异常。我不愿意在辩论中偏袒任何一方(双方都有很好的论据!)，但相当多的专家认为，事后看来，受控例外是一个错误的决定。

对于一些讨论，请查看维基百科网站的“已检查异常的价值可疑”。另一个早期广泛争论的例子是Rod Waldhoff的博客文章。

你是正确的。

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

例如:

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

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.

当你想要向调用者提供信息时，受控异常对于可恢复的情况很有用(例如，权限不足，文件未找到等)。

未检查异常很少用于在运行时通知用户或程序员严重错误或意外情况。如果你编写的代码或库将被其他人使用，不要抛出这些异常，因为他们可能不希望你的软件抛出未经检查的异常，因为编译器不会强制捕获或声明这些异常。

受控异常非常好，只要你知道什么时候应该使用它们。对于SQLException(有时对于IOException)， Java核心API无法遵循这些规则，这就是它们如此糟糕的原因。

受控异常应该用于可预测的、但无法预防的、可以合理恢复的错误。

未检查异常应该用于其他所有事情。

我来解释一下，因为大多数人都误解了这句话的意思。

Predictable but unpreventable: The caller did everything within their power to validate the input parameters, but some condition outside their control has caused the operation to fail. For example, you try reading a file but someone deletes it between the time you check if it exists and the time the read operation begins. By declaring a checked exception, you are telling the caller to anticipate this failure. Reasonable to recover from: There is no point telling callers to anticipate exceptions that they cannot recover from. If a user attempts to read from an non-existing file, the caller can prompt them for a new filename. On the other hand, if the method fails due to a programming bug (invalid method arguments or buggy method implementation) there is nothing the application can do to fix the problem in mid-execution. The best it can do is log the problem and wait for the developer to fix it at a later time.

除非您抛出的异常满足上述所有条件，否则它应该使用未检查异常。

Reevaluate at every level: Sometimes the method catching the checked exception isn't the right place to handle the error. In that case, consider what is reasonable for your own callers. If the exception is predictable, unpreventable and reasonable for them to recover from then you should throw a checked exception yourself. If not, you should wrap the exception in an unchecked exception. If you follow this rule you will find yourself converting checked exceptions to unchecked exceptions and vice versa depending on what layer you are in.

对于已检查和未检查的异常，使用正确的抽象级别。例如，具有两种不同实现(数据库和文件系统)的代码存储库应该通过抛出SQLException或IOException来避免暴露特定于实现的细节。相反，它应该将异常包装在一个跨越所有实现的抽象中(例如RepositoryException)。