不要捕获泛型异常在复杂的软件中，经常会有一些特定的代码块执行时会抛出多种不同异常的方法。动态装入一个类和实例化一个对象都可能会产生几个不同的异常，包括ClassNotFoundException, InstantiationException, IllegalAccessException, 和 ClassCastException。
一个繁忙的程序员在遇到这种情况时可能简单的把方法调用包在一个只会捕获泛型异常Exception的try/catch块，而不是添加四个不同的catch块到try块后面(看下面的代码清单３)。这看起来似乎无可置否，却会产生一些无意识的副面效果。例如，如果className()是null,那么Class.forName()将会抛出一个NullPointerException异常并在这个方法中被捕获。在这种情况下，catch块将捕获此异常虽然它从没打算去捕获这样一个异常，只是因为NullPointerException是RuntimeException的一个子类，而且RuntimeException又是Exception的一个子类。所以一个普通的catch(Exception e)将会捕获所有RuntimeException的子类，包括NullPointerException, IndexOutOfBoundsException, 和ArrayStoreException。通常，一个程序员并不打算去捕获这些异常。
在代码清单3中,null的className会导致一个NullPointerException异常产生，它告诉在调用的方法中类名无效。
代码清单3
public SomeInterface buildInstance(String className) {
SomeInterface impl = null;
try {
Class clazz = Class.forName(className);
impl = (SomeInterface)clazz.newInstance();
}
catch (Exception e) {
log.error("Error creating class: " + className);
}
return impl;
}
另一个使用泛型捕获子句的结果是限制日志记录，因为catch不知道到底那一个特殊的异常被捕获。有些程序员在面对这种问题的时候，采取添加检测的手段去查看异常的类型(代码清单4)，而这正好与使用catch块的目的相背离。
代码清单4
catch (Exception e) {
if (e instanceof ClassNotFoundException) {
log.error("Invalid class name: " + className + ", " + e.toString());
}
else {
log.error("Cannot create class: " + className + ", " + e.toString());
}
}
代码清单5提供一种完整的捕获特殊异常的例子，一些程序员可能会对它感趣。操作符instanceof不是必须的因为这个特殊的异常自会被捕获。每一个被检查的异常(ClassNotFoundException, InstantiationException, IllegalAccessException) 会被捕获和处理。对于一个类装入正确，但是却没有实现SomeInterface接口这种特殊情况会产生一个ClassCastException异常，这个异常也会被查证。
代码清单5
public SomeInterface buildInstance(String className) {
SomeInterface impl = null;
try {
Class clazz = Class.forName(className);
impl = (SomeInterface)clazz.newInstance();
}
catch (ClassNotFoundException e) {
log.error("Invalid class name: " + className + ", " + e.toString());
}
catch (InstantiationException e) {
log.error("Cannot create class: " + className + ", " + e.toString());
}
catch (IllegalAccessException e) {
log.error("Cannot create class: " + className + ", " + e.toString());
}
catch (ClassCastException e) {
log.error("Invalid class type, " + className
+ " does not implement " + SomeInterface.class.getName());
}
return impl;
}
在某些情况下，更好的方法是重新抛出一个已知的异常（或者叫创建一个新的异常）而不是试图去在当前这个方法中处理。这允许调用方法通过放置这个异常到一个已知的上下文中去处理这种错误情形。
下面的代码清单6提供了一个buildInterface()方法的替换版本。如果在装入和实例化类时发生问题，这个版本会抛出一个ClassNotFoundException异常。在这个例子中，调用方法会确保得到一个正确的实例化对象或者是一个异常。这样调用方法就不需要去检查返回的对象是否为空了。
注意这个例子使用了Java 1.4的方法来创建一个已经被另外的异常封装的新的异常，以便保存原始的堆栈跟踪信息。否则，堆栈跟踪将指明方法buildInstance()是引起异常的源，而不是潜在的由newInstance()抛出的异常。
代码清单6
public SomeInterface buildInstance(String className)
throws ClassNotFoundException {
try {
Class clazz = Class.forName(className);
return (SomeInterface)clazz.newInstance();
}
catch (ClassNotFoundException e) {
log.error("Invalid class name: " + className + ", " + e.toString());
throw e;
}
catch (InstantiationException e) {
throw new ClassNotFoundException("Cannot create class: " + className, e);
}
catch (IllegalAccessException e) {
throw new ClassNotFoundException("Cannot create class: " + className, e);
}
catch (ClassCastException e) {
throw new ClassNotFoundException(className
+ " does not implement " + SomeInterface.class.getName(), e);
}
}
在有些情况下，这段代码可能无法从某种错误状态恢复，这时，捕获一个特殊的异常以使代码能指出某种状态是否是可恢复的就变得很重要了。请试着以这种观点去看代码清单6中类实例化的例子。
在代码清单7中，如果className无效，程序会返回一个缺省的对象，并且抛出一个异常以指明非法的操作，比如错误的转型或访问权限不够。
注意：IllegalClassException是一系列的异常类，为示范的目的而在这提及（译注：并不是Java标准库所带）。
代码清单7
public SomeInterface buildInstance(String className)
throws IllegalClassException {
SomeInterface impl = null;
try {
Class clazz = Class.forName(className);
return (SomeInterface)clazz.newInstance();
}
catch (ClassNotFoundException e) {
log.warn("Invalid class name: " + className + ", using default");
}
catch (InstantiationException e) {
log.warn("Invalid class name: " + className + ", using default");
}
catch (IllegalAccessException e) {
throw new IllegalClassException("Cannot create class: " + className, e);
}
catch (ClassCastException e) {
throw new IllegalClassException(className
+ " does not implement " + SomeInterface.class.getName(), e);
}
if (impl == null) {
impl = new DefaultImplemantation();
}
return impl;
}
什么时候应捕获一个泛型异常？
在某些情况下捕获一个泛型异常是可以的，比如当它很便利且必需去捕获一个泛型异常的时候。这种情况非常特殊，且对于大型、允许失败的系统来说很重要。在代码清单8中，从一个请求队列中读取请求并顺序处理。但是，当请求被处理时候如果有任何异常发生（一个BadRequestException或任何RuntimeException的子类，包括NullpointerException），则那个异常就会被while循环外部所捕获。这样任何错误都会引起循环终止并且任何剩余的请求都不会被处理。那意味着在请求处理期间去处理一个错误是一种较差的方法。
代码清单8
public void processAllRequests() {
Request req = null;
try {
while (true) {
req = getNextRequest();
if (req != null) {
processRequest(req); // throws BadRequestException
}
else {
// Request queue is empty, must be done
break;
}
}
}
catch (BadRequestException e) {
log.error("Invalid request: " + req, e);
}
}
操作请求处理的一种较好的方法是对上述代码的逻辑作两个重要的改变，首先，将try/catch块移入请求处理的循环中。那样的话任何错误都会在循环内部被捕获和处理，并且不会引起循环终止。因而，循环会继续处理请求，即使一个单个的请求失败。第二，更改这个try/catch块使它去捕获一个泛型的异常。这样，任何异常都在循环内部被捕获，请求也得以继续处理。请看下面代码清单9：
代码清单9：
public void processAllRequests() {
while (true) {
Request req = null;
try {
req = getNextRequest();
if (req != null) {
processRequest(req); // Throws BadRequestException
}
else {
// Request queue is empty, must be done
break;
}
}
catch (Exception e) {
log.error("Error processing request: " + req, e);
}
}
}
捕获一个泛型异常听起来好像直接与本篇开始的观点相违背，确实如此。但是，这只是在非常非常特殊的的环境下。在这种情况下，捕获一个泛型的异常以防止一个单个的异常终止整个系统运行。
在请求、事务或事件在一个循环中被处理的情况下，即使在处理期间有异常被抛出，那个循环仍需要执行以便继续去处理。
在代码清单9中，在处理循环中try/catch块被认为是顶级异常管理者（the top-level exception handler），并且它需要捕获和记录所有在这个代码级别引起的异常。这样，异常没有被忽略，也不会丢失，并且异常不会中断余下需要处理的请求。
每个大型、复杂的系统都有一个顶级异常管理者（或者是每一个子系统，这取决于系统如何完成处理的）。顶级异常管理者无意去修复由异常引起的潜在问题，并且能在不终止处理的情况下捕获和记录这个问题。这并不是暗示所有的异常都应该在这个级别被抛出。任何异常如果能在较低级别被处理，则就应该那么做。如果那样，异常处理对问题发生时的状态逻辑就会知道的更多。但是，如果异常不能在较低级别被处理，那么抛出它到更高级别，这样，所有那些不可恢复的错误都将在一处被处理（顶级异常管理者），而不是遍及整个系统。
不要抛掷泛型异常
出现在程序清单1中的整个问题是在程序员决定从cleanupEverything()方法中抛掷泛型异常开始的，如此一来代码变得很优美，而当一个方法抛出6个不同异常时则会变得杂乱:方法声明变得得以理解，调用方法也不得不捕获那6个不同的异常，就像代码清单10那样。
代码清单10
public void cleanupEverything() throws
ExceptionOne, ExceptionTwo, ExceptionThree,
ExceptionFour, ExceptionFive, ExceptionSix {
cleanupConnections();
cleanupFiles();
removeListeners();
}
public void done() {
try {
doStuff();
cleanupEverything();
doMoreStuff();
}
catch (ExceptionOne e1) {
// Log e1
}
catch (ExceptionTwo e2) {
// Log e2
}
catch (ExceptionThree e3) {
// Log e3
}
catch (ExceptionFour e4) {
// Log e4
}
catch (ExceptionFive e5) {
// Log e5
}
catch (ExceptionSix e6) {
// Log e6
}
}
但是，即使代码有点杂乱，却很清楚。使用特殊异常可以避免两种非常真实的问题：抛掷一个泛型Exception隐藏了潜在问题的细节，这样也就失去了处理问题之所在的机会。更进一步说，抛掷一个泛型异常会强制任何调用这个的方法的代码要么捕获那个泛型异常（正像前述一样，这种方法有问题），要么重新抛掷那个泛型异常扩大问题范围。
有代表性的是，当一个方法声明它将抛出一个泛型异常Exception时，它这样做可能有以下两个原因之一：一种原因是，这个方法调用了几个另外的方法，而那几个方法可能会抛掷出许多不同的异常（比如调停者模式或门面模式），且隐藏了异常状态的细节。因此不论是什么问题这个方法只是简单的声明它会抛出Exception，而不创建和抛掷一层异常（封装在较低级别的异常）。另外一种情形是，在方法实例化和抛掷泛型异常Exception（即throw new Exception())的地方，因为程序员认为异常事实上不应该被用来表达这种情形。
这两方面的问题只要稍微思考和设计，就都可解决。什么是细节？那一层异常真的应该被抛掷吗？这个设计可能包括仅仅声明这个方法会抛掷一些确实会发生的异常。另一个选择是创建一层异常去封装抛掷和声明异常的东西。在大多数情况下，被方法抛掷的异常（或者叫一系列异常）应该尽可能的详细。这种更详细的异常会提供更多关于错误状态的信息，这样就允许这种情形被处理或至少详细的被记录。
如果泛型Exception类被选中，那就意味着任何调用一个声明了会抛出Exception方法的方法，要么必须声明它本身也会抛出Exception，要么封装这个方法调用在一个捕获泛型Exception的try/catch块中。我用这种方法在前面解释了这个问题。
小心使用泛型异常
这篇文章探究了处理泛型异常的几个方面：它们永远都不要被抛掷，也不应被忽略。它们应该很少被捕获（只在非常特殊的情况下）。它们不会提供详细信息以允许你去有效的处理它们，所以你不打算那样做时你应该小心捕获异常。
异常是Java中的一种强有力的工具。如果你正确使用，它能使你成为一个更有效率的程序员，并且缩短你的开发周期，特别是在测试和调试时。当异常被错误的使用时，在你的系统中，由于隐藏了问题的所在，你得一次又一次的重复工作。所以你要关注好你在哪和如何使用泛型异常。
