我们已经看到了c#首席架构师的一些参考。

下面是Java人员关于何时使用受控异常的另一种观点。他承认了其他人提到的许多负面因素: 有效的异常

这并不是反对受控异常的纯概念，但是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 !

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

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

以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()一样懒惰;仍然在不确定的状态下继续编写代码。另外，特定日志系统或其他处理程序的选择是特定于应用程序的，因此这会影响代码重用。

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

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

受控异常的一个问题是，如果一个接口的一个实现使用了它，异常通常会附加到该接口的方法上。

受控异常的另一个问题是它们容易被滥用。java.sql就是一个完美的例子。连接的close()方法。它可以抛出一个SQLException，即使您已经显式地声明您已经完成了连接。close()可能传达了哪些您所关心的信息?

通常，当我关闭()一个连接*时，它看起来像这样:

try {
    conn.close();
} catch (SQLException ex) {
    // Do nothing
}

另外，不要让我开始各种解析方法和NumberFormatException... .NET的TryParse，它不抛出异常，使用起来要容易得多，以至于不得不回到Java(我工作的地方同时使用Java和c#)。

*作为额外的注释，PooledConnection的connection .close()甚至不关闭连接，但您仍然必须捕获SQLException，因为它是一个已检查异常。

尽管阅读了整页，我仍然找不到一个反对受控异常的合理论点。相反，大多数人都在谈论糟糕的API设计，无论是在一些Java类中还是在他们自己的类中。

这个功能唯一令人讨厌的地方就是原型设计。这可以通过向语言中添加一些机制来解决(例如，一些@supresscheckedexceptions注释)。但是对于常规编程，我认为受控异常是一件好事。

Robert C. Martin在他的著作《Clean Code》中也不推荐使用受控异常，他认为受控异常违反了开闭原则:

什么价格?受控异常的价格是Open/Closed Principle1侵犯。如果从方法抛出checked异常 在您的代码中，并且catch高于三级，您必须声明 实例之间的每个方法签名中的异常 抓住。这意味着在软件的低级别上的更改可以 在许多更高级别上强制更改签名。变更的模块 必须重建和重新部署，即使他们不关心 改变了。