读书，收获，分享
建议后面的五角星仅代表笔者个人需要注意的程度。
Talk is cheap.Show me the code
建议110：提倡异常封装★★☆☆☆
Java API提供的异常只有开发人员才能看得懂，而对于终端用户来说，这些异常基本上就是天书，那该怎么办？这就需要我们对异常进行封装了。异常封装有三方面的优点：
-
提高系统的友好性，如下：
public static void doStuff2() throws MyBussinessException{ try { InputStream is = new FileInputStream("无效文件.txt"); } catch (FileNotFoundException e) { //为方便开发和维护人员而设置的异常信息 e.printStackTrace(); //抛出业务异常 throw new MyBussinessException(e); } /*文件操作*/ } -
提高系统的可维护性，如下：
public void doStuff2(){ try{ //do something }catch(FileNotFoundException e){ log.info("文件问找到，使用默认配置文件……"); }catch(SecurityException e){ log.error("无权访问，可能原因是……"); e.printStackTrace(); } } -
解决Java异常机制自身的缺陷(Java中的异常一次只能抛出一个)。如下：
class MyException extends Exception { // 容纳所有的异常 private List<Throwable> causes = new ArrayList<Throwable>(); // 构造函数，传递一个异常列表 public MyException(List<? extends Throwable> _causes) { causes.addAll(_causes); } // 读取所有的异常 public List<Throwable> getExceptions() { return causes; } } public static void doStuff() throws MyException { List<Throwable> list = new ArrayList<Throwable>(); // 第一个逻辑片段 try { // Do Something } catch (Exception e) { list.add(e); } // 第二个逻辑片段 try { // Do Something } catch (Exception e) { list.add(e); } if (list.size() > 0) { throw new MyException(list); } }
建议111：采用异常链传递异常★★☆☆☆
设计模式中有一个模式叫做责任链模式（Chain of Responsibility），它的目的是将多个对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止，异常的传递处理也应该采用责任链模式。
对于异常先封装，然后传递，过程如下：
- 把
FileNotFoundException封装为MyException。 - 抛出到逻辑层，逻辑层根据异常代码（或者自定义的异常类型）确定后续处理逻辑，然后抛出到展现层。
- 展现层自行决定要展现什么，如果是管理员则可以展现低层级的异常，如果是普通用户则展示封装后的异常。
示例如下：
public class IOException extends Exception {
public IOException() {
super();
}
//定义异常原因
public IOException(String message) {
super(message);
}
//定义异常原因，并携带原始异常
public IOException(String message, Throwable cause) {
super(message, cause);
}
//保留原始异常信息
public IOException(Throwable cause) {
super(cause);
}
}
//调用
try{
//doSomething
}catch(Exception e){
throw new IOException(e);
}
建议112：受检异常尽可能转化为非受检异常★☆☆☆☆
受检异常不足的地方：
-
受检异常使接口声明脆弱
interface User{ //修改用户密码，抛出安全异常 public void changePassword() throws MySecurityException; } //这会导致所有的User调用者都要追加对RejectChangeException异常问题的处理。 -
受检异常使代码的可读性降低
public static void main(String[] args) { //调用者必须对异常进行处理 try{ user.changePassword(); }catch(Exception e){ e.printStackTrace(); } } 受检异常增加了开发工作量
注意：受检异常威胁到系统的安全性、稳定性、可靠性、正确性时，不能转换为非受检异常。
建议113：不要在finally块中处理返回值★☆☆☆☆
可能会引发以下问题：
-
覆盖了
try代码块中的return返回值public static Person doStuffw() { Person person = new Person(); person.setName("张三"); try { return person; } catch (Exception e) { } finally { // 重新修改一下值 person.setName("李四"); } person.setName("王五"); return person; } -
屏蔽异常
public static void doSomeThing(){ try{ //正常抛出异常 throw new RuntimeException(); }finally{ //告诉JVM：该方法正常返回 return; } }
注意：不要在
finally代码块中出现return语句。
建议114：不要在构造函数中抛出异常★☆☆☆☆
Java的异常机制有三种：
-
Error类及其子类表示的是错误，无法处理。 -
RuntimeException类及其子类表示的是非受检异常，需要处理。 -
Exception类及其子类（不包含非受检异常）表示的是受检异常，必须处理。
从系统设计和开发的角度来分析，尽量不要在构造函数中抛出异常，原因分析：
构造函数抛出错误是程序员无法处理的
-
构造函数不应该抛出非受检异常
- 加重了上层代码编写者的负担
- 后续代码不会执行
-
构造函数尽可能不要抛出受检异常
- 导致子类代码膨胀
- 违背了里氏替换原则，里氏替换原则是说“父类能出现的地方子类就可以出现，而且将父类替换为子类也不会产生任何异常”
- 子类构造函数扩展受限
建议115：使用Throwable获得栈信息★☆☆☆☆
JVM在创建一个Throwable类及其子类时会把当前线程的栈信息记录下来，以便在输出异常时准确定位异常原因，我们来看Throwable源代码：
public class Throwable implements Serializable {
//出现异常记录的栈帧
private StackTraceElement[] stackTrace;
//默认构造函数
public Throwable() {
//记录栈帧
fillInStackTrace();
}
//本地方法，抓取执行时的栈信息
private synchronized native Throwable fillInStackTrace();
}
在出现异常时（或主动声明一个Throwable对象时），JVM会通过fillInStackTrace方法记录下栈帧信息，然后生成一个Throwable对象，这样我们就可以知道类间的调用顺序、方法名称及当前行号等了。
建议116：异常只为异常服务★☆☆☆☆
异常虽然是描述例外事件的，但能避免则避免。
建议在异常诞生前就消除掉，比如增加判断，以提高程序的性能和稳定性。
注意：异常只为确实异常的事件服务。
建议117：多使用异常，把性能问题放一边★☆☆☆☆
异常有一个缺点：性能比较慢。
Java的异常处理机制确实比较慢，这个“比较慢”是相对于诸如String、Integer等对象来说的，单单从对象的创建上来说，new一个IOException会比String慢5倍，这从异常的处理机制上也可以解释：因为它要执行fillInStackTrace方法，要记录当前栈的快照，而String类则是直接申请一个内存创建对象，异常类慢一筹也就在所难免了。而且，异常类是不能缓存的。
经过测试，在JDK 1.6下，一个异常对象创建的时间只需要1.4毫秒左右（注意是毫秒，通常一个交易处理是在100毫秒左右），难道我们的系统连如此微小的性能消耗都不允许吗？
注意：性能问题不是拒绝异常的借口。
