Effective Java(3rd)-Item70 对可恢复条件使用已检查异常，对编程错误使用运行时异常

  Java提供了三种可抛出对象:已检查异常、运行时异常和错误。程序员们对什么时候使用每种异常比较困惑。虽然决策并不总是明确的，但是有一些通用规则可以提供强有力的指导。
  决定是否使用检查异常或未检查异常的基本规则是:对于可以合理地期望调用者从中恢复的条件，请使用已检查异常。通过抛出一个已检查的异常，您可以强制调用者在catch子句中处理异常，或者将其传播出去。因此，声明要抛出方法的每个已检查异常都有力地向API用户表明，关联的条件是调用该方法的可能结果。
  通过向用户提供已检查异常，API设计器提供了从条件中恢复的命令。用户可以通过捕获异常并忽略它来忽略强制命令，但这通常不是一个好主意( item77 )。

  有两种未检查的可抛出项:运行时异常和错误。它们的行为是相同的:这两种都是一次性的，不需要，通常也不应该被捕获。如果程序抛出未检查的异常或错误，通常情况下恢复是不可能的，继续执行弊大于利。如果程序没有捕捉到这样的可抛出对象，它将导致当前线程停止，并发出适当的错误消息。
  使用运行时异常来指示编程错误。绝大多数运行时异常都表示违反了先决条件。违反先决条件只是API的客户端未能遵守API规范所建立的契约。例如，数组访问契约指定数组索引必须在0和数组长度- 1之间，包括0和- 1。ArrayIndexOutOfBoundsException表示违反了此先决条件。

  这个建议的一个问题是，并不总是清楚您是在处理可恢复的条件还是编程错误。例如，考虑资源耗尽的情况，这可能是由编程错误(如分配一个不合理的大数组)或真正的资源短缺造成的。如果资源枯竭是由于暂时短缺或暂时需求增加造成的，这种情况很可能是可以恢复的。对于API设计人员来说，判断给定的资源耗尽实例是否允许恢复是一个问题。如果您认为某个条件可能允许恢复，请使用已检查的异常;如果没有，使用运行时异常。如果不清楚是否可以恢复，最好使用未检查的异常，原因将在第71项中讨论。
  虽然Java语言规范不需要它，但有一个强烈的约定，即errors保留给JVM使用，以指示资源不足、不变的故障或其他导致无法继续执行的条件。考虑到几乎普遍接受这种约定，最好不要实现任何新的Error子类。因此，您实现的所有未选中的可抛出项都应该继承RuntimeException子类(直接或间接地)。不仅不应该定义错误子类，而且除了AssertionError之外，也不应该抛出它们。
  可以定义一个不是Exception、RuntimeException或Error的子类的throwable。：JLS不直接处理这些可抛出类，而是隐式地指定它们作为普通的检查异常(它们是Exception的子类，但不是RuntimeException)。那么，什么时候应该使用这样的野兽呢?总之，永远不会。与普通的检查异常相比，它们没有任何好处，只会让API的用户感到困惑。
  API设计人员常常忘记异常是可以定义任意方法的成熟对象。此类方法的主要用途是提供捕获异常的代码，并提供有关引发异常的条件的附加信息。在缺乏此类方法的情况下，已知程序员会解析异常的字符串表示，以获取更多信息。这是极坏的做法( item12 )。可抛出类很少指定其字符串表示的细节，因此字符串表示可能因实现而异，也可能因发布而异。因此，解析异常的字符串表示形式的代码可能是不可移植和脆弱的。

  为检查异常通常表示可恢复的条件，所以对它们来说，提供提供信息的方法来帮助调用者从异常条件中恢复尤为重要。例如，假设当使用礼品卡购物的尝试由于资金不足而失败时，抛出一个已检查的异常。异常应该提供一个访问器方法来查询差额的数量。这将使调用者能够将金额传递给购物者。有关此主题的更多信息，请参见项目75。
  总而言之，为可恢复条件抛出已检查异常，为编程错误抛出未检查异常。当有疑问时，抛出未检查的异常。不要定义任何既不是已检查异常也不是运行时异常的可抛出项。提供检查异常的方法来帮助恢复。
本文写于2019.7.22，历时1天