《有效的Java异常》一文很好地解释了什么时候使用未检查的异常，什么时候使用已检查的异常。以下是那篇文章中的一些引语，以突出其要点:

应急预案: 一种期望的条件，要求方法提供可根据该方法的预期目的来表达的替代响应。方法的调用者期望这些类型的条件，并有一个策略来处理它们。 错: 一种计划外的情况，阻止方法实现其预期目的，如果不参考方法的内部实现，则无法描述该情况。

(SO不支持表格，所以你可能想从原始页面阅读以下内容…)

Contingency Is considered to be: A part of the design Is expected to happen: Regularly but rarely Who cares about it: The upstream code that invokes the method Examples: Alternative return modes Best Mapping: A checked exception Fault Is considered to be: A nasty surprise Is expected to happen: Never Who cares about it: The people who need to fix the problem Examples: Programming bugs, hardware malfunctions, configuration mistakes, missing files, unavailable servers Best Mapping: An unchecked exception

我知道这是一个老问题，但我花了一段时间与受控异常搏斗，我有一些东西要补充。请原谅我的长度!

我对受控异常的主要不满是它们破坏了多态性。让它们很好地与多态接口一起工作是不可能的。

以Java List界面为例。我们有常见的内存实现，比如ArrayList和LinkedList。我们还有骨架类AbstractList，这使得设计新的列表类型变得很容易。对于只读列表，我们只需要实现两个方法:size()和get(int index)。

这个例子类WidgetList从一个文件中读取一些固定大小的Widget类型的对象(没有显示出来):

class WidgetList extends AbstractList<Widget> {
    private static final int SIZE_OF_WIDGET = 100;
    private final RandomAccessFile file;

    public WidgetList(RandomAccessFile file) {
        this.file = file;
    }

    @Override
    public int size() {
        return (int)(file.length() / SIZE_OF_WIDGET);
    }

    @Override
    public Widget get(int index) {
        file.seek((long)index * SIZE_OF_WIDGET);
        byte[] data = new byte[SIZE_OF_WIDGET];
        file.read(data);
        return new Widget(data);
    }
}

By exposing the Widgets using the familiar List interface, you can retrieve items (list.get(123)) or iterate a list (for (Widget w : list) ...) without needing to know about WidgetList itself. One can pass this list to any standard methods that use generic lists, or wrap it in a Collections.synchronizedList. Code that uses it need neither know nor care whether the "Widgets" are made up on the spot, come from an array, or are read from a file, or a database, or from across the network, or from a future subspace relay. It will still work correctly because the List interface is correctly implemented.

但事实并非如此。上面的类不能编译，因为文件访问方法可能会抛出一个IOException，一个你必须“捕获或指定”的受控异常。您不能将其指定为抛出——编译器不会允许您这样做，因为这会违反List接口的约定。而且WidgetList本身也没有处理异常的有用方法(我将在后面详细说明)。

显然，唯一要做的事情是捕获并重新抛出已检查异常作为一些未检查的异常:

@Override
public int size() {
    try {
        return (int)(file.length() / SIZE_OF_WIDGET);
    } catch (IOException e) {
        throw new WidgetListException(e);
    }
}

public static class WidgetListException extends RuntimeException {
    public WidgetListException(Throwable cause) {
        super(cause);
    }
}

(编辑:Java 8为这种情况添加了UncheckedIOException类:用于跨多态方法边界捕获和重新抛出ioexception。有点证明了我的观点!))

So checked exceptions simply don't work in cases like this. You can't throw them. Ditto for a clever Map backed by a database, or an implementation of java.util.Random connected to a quantum entropy source via a COM port. As soon as you try to do anything novel with the implementation of a polymorphic interface, the concept of checked exceptions fails. But checked exceptions are so insidious that they still won't leave you in peace, because you still have to catch and rethrow any from lower-level methods, cluttering the code and cluttering the stack trace.

我发现，无处不在的Runnable接口如果调用了抛出受控异常的东西，就经常会退到这个角落。它不能按原样抛出异常，所以它所能做的就是通过捕获并作为RuntimeException重新抛出而使代码变得混乱。

实际上，如果使用hack，可以抛出未声明的受控异常。JVM在运行时并不关心受控异常规则，因此我们只需要欺骗编译器。最简单的方法就是滥用泛型。这是我的方法(类名显示，因为(在Java 8之前)它是通用方法调用语法中必需的):

class Util {
    /**
     * Throws any {@link Throwable} without needing to declare it in the
     * method's {@code throws} clause.
     * 
     * <p>When calling, it is suggested to prepend this method by the
     * {@code throw} keyword. This tells the compiler about the control flow,
     * about reachable and unreachable code. (For example, you don't need to
     * specify a method return value when throwing an exception.) To support
     * this, this method has a return type of {@link RuntimeException},
     * although it never returns anything.
     * 
     * @param t the {@code Throwable} to throw
     * @return nothing; this method never returns normally
     * @throws Throwable that was provided to the method
     * @throws NullPointerException if {@code t} is {@code null}
     */
    public static RuntimeException sneakyThrow(Throwable t) {
        return Util.<RuntimeException>sneakyThrow1(t);
    }

    @SuppressWarnings("unchecked")
    private static <T extends Throwable> RuntimeException sneakyThrow1(
            Throwable t) throws T {
        throw (T)t;
    }
}

华友世纪!使用此方法，我们可以在堆栈的任何深度抛出检查异常，而无需声明它，无需将其包装在RuntimeException中，也不会使堆栈跟踪变得混乱!再次使用"WidgetList"的例子:

@Override
public int size() {
    try {
        return (int)(file.length() / SIZE_OF_WIDGET);
    } catch (IOException e) {
        throw sneakyThrow(e);
    }
}

不幸的是，对受控异常的最后一种侮辱是，如果编译器认为无法抛出受控异常，则拒绝允许您捕获该异常。(未检查的异常没有此规则。)要捕获偷偷抛出的异常，我们必须这样做:

try {
    ...
} catch (Throwable t) { // catch everything
    if (t instanceof IOException) {
        // handle it
        ...
    } else {
        // didn't want to catch this one; let it go
        throw t;
    }
}

这有点尴尬，但从好的方面来看，它仍然比提取包装在RuntimeException中的受控异常的代码稍微简单一些。

高兴的是，扔t;语句在这里是合法的，尽管检查了t的类型，这要归功于Java 7中添加的关于重新抛出捕获的异常的规则。

---

When checked exceptions meet polymorphism, the opposite case is also a problem: when a method is spec'd as potentially throwing a checked exception, but an overridden implementation doesn't. For example, the abstract class OutputStream's write methods all specify throws IOException. ByteArrayOutputStream is a subclass that writes to an in-memory array instead of a true I/O source. Its overridden write methods cannot cause IOExceptions, so they have no throws clause, and you can call them without worrying about the catch-or-specify requirement.

但并非总是如此。假设Widget有一个保存到流的方法:

public void writeTo(OutputStream out) throws IOException;

声明这个方法接受普通的OutputStream是正确的做法，因此它可以多态地用于各种输出:文件、数据库、网络等等。以及内存数组。然而，对于内存中的数组，有一个虚假的要求来处理一个实际上不会发生的异常:

ByteArrayOutputStream out = new ByteArrayOutputStream();
try {
    someWidget.writeTo(out);
} catch (IOException e) {
    // can't happen (although we shouldn't ignore it if it does)
    throw new RuntimeException(e);
}

像往常一样，受控异常会成为阻碍。如果变量声明为具有更多开放式异常需求的基类型，则必须为这些异常添加处理程序，即使您知道它们不会出现在应用程序中。

但是等等，受控异常实际上非常烦人，它们甚至不允许您做相反的事情!想象一下，您当前捕获了OutputStream上的write调用抛出的任何IOException，但您想将变量的声明类型更改为ByteArrayOutputStream，编译器将斥责您试图捕获它说不能抛出的检查异常。

That rule causes some absurd problems. For example, one of the three write methods of OutputStream is not overridden by ByteArrayOutputStream. Specifically, write(byte[] data) is a convenience method that writes the full array by calling write(byte[] data, int offset, int length) with an offset of 0 and the length of the array. ByteArrayOutputStream overrides the three-argument method but inherits the one-argument convenience method as-is. The inherited method does exactly the right thing, but it includes an unwanted throws clause. That was perhaps an oversight in the design of ByteArrayOutputStream, but they can never fix it because it would break source compatibility with any code that does catch the exception -- the exception that has never, is never, and never will be thrown!

That rule is annoying during editing and debugging too. E.g., sometimes I'll comment out a method call temporarily, and if it could have thrown a checked exception, the compiler will now complain about the existence of the local try and catch blocks. So I have to comment those out too, and now when editing the code within, the IDE will indent to the wrong level because the { and } are commented out. Gah! It's a small complaint but it seems like the only thing checked exceptions ever do is cause trouble.

---

我快做完了。我对受控异常的最后一个不满是，在大多数调用站点上，没有什么有用的东西可以用它们来做。理想情况下，当出现问题时，我们应该有一个称职的特定于应用程序的处理程序，可以通知用户问题和/或适当地结束或重试操作。只有堆栈中较高的处理程序才能做到这一点，因为它是唯一知道总体目标的处理程序。

相反，我们得到了下面的习语，这是一种关闭编译器的猖獗方式:

try {
    ...
} catch (SomeStupidExceptionOmgWhoCares e) {
    e.printStackTrace();
}

在GUI或自动化程序中，打印的消息将不会被看到。更糟糕的是，它在异常之后继续执行其余代码。异常实际上不是一个错误吗?那就别印出来。否则，马上就会出现其他异常，此时原始异常对象将消失。这个习惯用法不比BASIC的On Error Resume Next或PHP的error_reporting(0);更好。

调用某种类型的记录器类也好不到哪里去:

try {
    ...
} catch (SomethingWeird e) {
    logger.log(e);
}

这就像e.p printstacktrace()一样懒惰;仍然在不确定的状态下继续编写代码。另外，特定日志系统或其他处理程序的选择是特定于应用程序的，因此这会影响代码重用。

但是等等!有一种简单而通用的方法可以找到特定于应用程序的处理程序。它位于调用堆栈的更高位置(或者它被设置为线程的未捕获异常处理程序)。因此，在大多数情况下，您所需要做的就是将异常抛出到堆栈的更高位置。例如，投掷;受控异常只会碍事。

我确信，在设计语言时，受控异常听起来是个好主意，但在实践中，我发现它们都很麻烦，而且没有任何好处。

好吧，这不是关于显示堆栈跟踪或无声崩溃。它是关于在层与层之间沟通错误的能力。

The problem with checked exceptions is they encourage people to swallow important details (namely, the exception class). If you choose not to swallow that detail, then you have to keep adding throws declarations across your whole app. This means 1) that a new exception type will affect lots of function signatures, and 2) you can miss a specific instance of the exception you actually -want- to catch (say you open a secondary file for a function that writes data to a file. The secondary file is optional, so you can ignore its errors, but because the signature throws IOException, it's easy to overlook this).

实际上，我现在在一个应用程序中处理这种情况。我们将异常重新打包为AppSpecificException。这使得签名非常干净，我们不必担心在签名中爆炸。

当然，现在我们需要在更高的级别上专门化错误处理，实现重试逻辑等等。所有的东西都是AppSpecificException，所以我们不能说“如果一个IOException被抛出，重试”或“如果ClassNotFound被抛出，完全中止”。我们没有可靠的方法来获得真正的异常，因为当它们在我们的代码和第三方代码之间传递时，东西会一次又一次地重新打包。

这就是为什么我非常喜欢python中的异常处理。你只能捕获你想要和/或能处理的东西。其他所有东西都冒出来了，就好像你自己重新扔了它一样(不管怎样你已经这么做了)。

我一次又一次地发现，在我提到的整个项目中，异常处理分为3类:

Catch and handle a specific exception. This is to implement retry logic, for example. Catch and rethrow other exceptions. All that happens here is usually logging, and its usually a trite message like "Unable to open $filename". These are errors you can't do anything about; only a higher levels knows enough to handle it. Catch everything and display an error message. This is usually at the very root of a dispatcher, and all it does it make sure it can communicate the error to the caller via a non-Exception mechanism (popup dialogue, marshaling an RPC Error object, etc).

这并不是反对受控异常的纯概念，但是Java用于受控异常的类层次结构是一个畸形秀。我们总是简单地称这些东西为“异常”——这是正确的，因为语言规范也这样称呼它们——但是异常在类型系统中是如何命名和表示的呢?

By the class Exception one imagines? Well no, because Exceptions are exceptions, and likewise exceptions are Exceptions, except for those exceptions that are not Exceptions, because other exceptions are actually Errors, which are the other kind of exception, a kind of extra-exceptional exception that should never happen except when it does, and which you should never catch except sometimes you have to. Except that's not all because you can also define other exceptions that are neither Exceptions nor Errors but merely Throwable exceptions.

哪些是“已检查”异常?可抛出异常是受控异常，除非它们也是错误，是未检查的异常，然后是异常，也是可抛出异常，是受控异常的主要类型，除了有一个例外，那就是if它们也是runtimeexception，因为那是另一种未检查的异常。

What are RuntimeExceptions for? Well just like the name implies, they're exceptions, like all Exceptions, and they happen at run-time, like all exceptions actually, except that RuntimeExceptions are exceptional compared to other run-time Exceptions because they aren't supposed to happen except when you make some silly error, although RuntimeExceptions are never Errors, so they're for things that are exceptionally erroneous but which aren't actually Errors. Except for RuntimeErrorException, which really is a RuntimeException for Errors. But aren't all exceptions supposed to represent erroneous circumstances anyway? Yes, all of them. Except for ThreadDeath, an exceptionally unexceptional exception, as the documentation explains that it's a "normal occurrence" and that that's why they made it a type of Error.

Anyway, since we're dividing all exceptions down the middle into Errors (which are for exceptional execution exceptions, so unchecked) and Exceptions (which are for less exceptional execution errors, so checked except when they're not), we now need two different kinds of each of several exceptions. So we need IllegalAccessError and IllegalAccessException, and InstantiationError and InstantiationException, and NoSuchFieldError and NoSuchFieldException, and NoSuchMethodError and NoSuchMethodException, and ZipError and ZipException.

只不过，即使检查了异常，也总有(相当简单的)方法可以欺骗编译器，在不检查的情况下抛出异常。如果你这样做，你可能会得到一个不确定的throwableexception，除非在其他情况下，它可能抛出一个意外的dexception，或一个未知的异常(与未知的错误无关，只针对“严重的异常”)，或一个ExecutionException，或一个InvocationTargetException，或一个ExceptionInInitializerError。

哦，我们一定不能忘记Java 8时髦的新UncheckedIOException，这是一个RuntimeException异常，设计用来通过包装由I/O错误(不会引起IOError异常，尽管也存在)引起的已检查的IOException异常来抛出异常检查的概念，这些异常异常难以处理，因此您需要它们不被检查。

由于Java !

Anders在软件工程电台的第97集中谈到了受控异常的陷阱，以及他为什么把它们排除在c#之外。

在过去的三年中，我一直在与一些开发人员一起开发相对复杂的应用程序。我们有一个代码库，它经常使用检查异常，并进行适当的错误处理，而其他一些代码库则没有。

So far, I have it found easier to work with the code base with Checked Exceptions. When I am using someone else's API, it is nice that I can see exactly what kind of error conditions I can expect when I call the code and handle them properly, either by logging, displaying or ignoring (Yes, there is valid cases for ignoring exceptions, such as a ClassLoader implementation). That gives the code I am writing an opportunity to recover. All runtime exceptions I propagate up until they are cached and handled with some generic error handling code. When I find a checked exception that I don't really want to handle at a specific level, or that I consider a programming logic error, then I wrap it into a RuntimeException and let it bubble up. Never, ever swallow an exception without a good reason (and good reasons for doing this are rather scarce)

当我使用没有检查异常的代码库时，它使我在调用函数时很难预先知道我期望什么，这可能会严重破坏一些东西。

当然，这完全取决于开发者的偏好和技能。编程和错误处理的两种方式可能同样有效(或无效)，所以我不会说只有一种方法。

总而言之，我发现使用受控异常更容易，特别是在有很多开发人员的大型项目中。