我知道这是一个老问题，但我花了一段时间与受控异常搏斗，我有一些东西要补充。请原谅我的长度!
我对受控异常的主要不满是它们破坏了多态性。让它们很好地与多态接口一起工作是不可能的。
以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()一样懒惰;仍然在不确定的状态下继续编写代码。另外，特定日志系统或其他处理程序的选择是特定于应用程序的，因此这会影响代码重用。
但是等等!有一种简单而通用的方法可以找到特定于应用程序的处理程序。它位于调用堆栈的更高位置(或者它被设置为线程的未捕获异常处理程序)。因此，在大多数情况下，您所需要做的就是将异常抛出到堆栈的更高位置。例如，投掷;受控异常只会碍事。
我确信，在设计语言时，受控异常听起来是个好主意，但在实践中，我发现它们都很麻烦，而且没有任何好处。
