检查异常是方法与其调用方之间的契约的一部分，抛出的异常总是需要以某种方式处理。
正确答案取决于具体情况：
调用方可以处理异常：

String getStringFromRemoteServer() throws IOException { ... }

String getConfigString() {
  try {
    return getStringFromRemoteServer();
  } catch (IOException e) {
    LOG.warn("Failed to contact server, using local version.", e);
    return getLocalString();
  }
}

在这种情况下，我们有一个我们需要的替代数据源，因此如果首选方法失败，我们将捕获异常，记录它（以便我们知道网络存在问题）并调用替代方法。
异常是致命的，我们不希望调用树中的任何更高级别的函数尝试处理它。

Configuration parseConfiguration(String configString) throws ParseException { ... }

void loadConfiguration() {
  try {
    this.globalConfig = parseConfiguration(getConfigString());
  } catch (ParseException e) {
    throw new RuntimeException("Corrupted config", e);
  }
}

在这种情况下，异常意味着应用程序的配置被严重破坏。试图处理这个错误是没有意义的，我们的任何调用者试图处理它也是没有意义的，所以声明 throws 在…上 loadConfiguration() 只会让人感到混乱。我们将异常 Package 在一个 RuntimeException 然后重新播放它。请注意，我们不记录它——将有一些未捕获异常的顶级报告，因此在这里记录它将是重复的。
它仍然是有价值的 parseConfiguration() 抛出一个选中的异常，因为当我们从交互式配置编辑器调用它时，我们捕获异常并向用户显示一条错误消息。
也许我们的调用者可以处理这个异常。

int stringToInteger(String s) throws BadNumberException { ... }

String decimalStringToHexString(String s) throws BadNumberException {
  return intToHex(stringToInteger(s));
}

在这种情况下，我们不会更改异常的含义-- decimalStringToHexString 正在从字符串转换数字，一个可能的结果是该字符串非法。我们的呼叫者需要意识到这是一种可能的结果，就像我们的呼叫者一样 stringToInteger() 是，因此我们只需声明异常并让调用方处理它。我们的调用者知道他们在其中使用数字的上下文，因此他们可以决定如何处理异常。
有两条规则：
永远不要完全忽略异常（好的，可能是interruptedexception）。如果你写信 try { ... } catch (Exception e) {} 空catch子句将使您很难发现代码不工作的原因。
Package 异常时，始终将原始异常作为原因。