猫头鹰的深夜翻译：趣谈Java Exception

前言

Java异常类（Exception）是用来处理异常程序行为的一组类。在这篇文章中，我将介绍如何使用Java异常类，以及在程序中如何设计Java异常体系。Exception类是Java体系中非常重要的一环，每一个程序员都必须熟悉并掌握它。

Java异常承载的信息量超乎你的想象

Java Exception的结构设计本身就可以提供给开发者非常多的信息（如果开发者可以恰当的利用这一结构）。Exception结构如下图所示：

Throwable是整个异常结构的父类，它有两个子类，分别是Error和Exception

Java Error

Error类代表出现非正常场景，一旦Error异常出现，整个应用程序可能崩溃。

Java Exception

Exception和Error类不同，当这种类型的异常出现时，程序是可以尝试恢复并继续运行的。Exception异常有以下两类，运行时异常（Runtime Exception）和非运行时异常（Not Runtime Exception）：

非运行时异常也成为checked异常，这一类异常和Error异常非常类似，二者的区别在于程序在抛出checked exception有更高的几率恢复正常。

Checked 和 Unchecked异常

Checked异常强制开发者在程序中进行处理或再次抛出。如果checked异常被重新抛出，则需要在方法中用throws语法声明该异常。与之相反，Unchecked异常不需要特殊处理。这种设计结构意味着不主动处理的unchecked异常将会被抛到根类。

如何在JAVA中进行异常处理

Java中有两种方式处理异常：在当前方法中处理或者是重新抛出。你可能需要一个父异常处理器，或者是执行一些其它特定逻辑，如进行重试。

如上文所示，我们可以将异常拆分成三类：Checked，Runtime和Error。它们分别在不同的场景下抛出，代表程序可以恢复的程度。最乐观的是Checked异常，Runtime异常相对而言可恢复的可能性更小，最糟糕的是Error类型异常。

在了解了异常的类型后，我们就可以试着回答以下问题：

• 程序当前情况有多糟糕？ 问题的原因是什么？
• 如何修复问题？
• 需要重启JVM吗？
• 需要重新编写代码吗？

熟悉异常后意味着我们可以推测程序是哪里出现了问题，并且试着修复它。下面的章节会展示几个经典的异常场景并分析原因（假设程序已经通过了编译自测阶段）

分析Error异常

先从最严重的Error异常说起。最常见的Error异常如下图所示：

在大多数情况下，你只需要修改JVM的配置或者添加缺少的依赖。当然，也有少部分场景需要对代码进行优化。

分析Checked异常

对于Checked异常，它通常代表着程序有可能用某种方式从这种异常中恢复过来，比如重试。下文将会给出几个比较经典的Checked异常，其中有些异常可能是另一些异常的父类，在此将无视这些异常中的关联进行分析。

所以，这张表说明了什么呢？如果你仔细观察，会发现大多数情况下不需要去修改代码，甚至不需要去重启应用程序。

分析Runtime异常

Runtime异常是最常见的异常。通常来说Checked和Error异常并不需要代码变更，但是Runtime异常通常意味着必须修改代码才能修复这个问题。下面的表格展示了最常见的Runtime异常：

可见Runtime异常会对程序带来多大的伤害。它是那个导致代码修复，程序员压力陡增和商业损失的罪魁祸首。

Checked异常导致的代码污染

根据Checked异常的定义，开发者应该将每一个可恢复的问题通过Checked异常抛出。但是这同时意味着需要在方法定义中强制声明这个异常，以及调用方必须额外增加三四行try-catch逻辑来对这个异常进行处理。如果程序中到处充斥着这样的代码片段，会极大影响代码的可读性。因此，我更推荐使用RuntimeException进行异常管理。即便是在设计API时，也可以通过在方法中定义Runtime异常加上注释辅助调用方理解。而API调用方则可以自己决定是否要处理这个异常还是继续向上抛出。

原文链接: dzone.com/articles/java-exceptions-1