异常处理的设计（一）

    今天开始我也要写一个讲JAVA异常的系列文章（我现在还不知道博客到底是按字数还是篇数攒积分），估计就是这个月的最后三篇吧，下个月要开始忙了。反正也没有人在博客里关心我到底忙不忙，我其实一直把博客当成技术日记，目前我的博客就只有存储的功能。
    言归正传。
    似乎Java异常这个东东的争议比较多，但资料、博客里讲的确缺限于分类啊处理啊很helloworld的，开发项目几乎可以被忽略一样。我这个系列也就谈谈我的一些体会吧，估计也不深....

他有啥不同？

其实异常还真没有啥本质的不同，Java里面都是class，因此对于一般java的设计原则同样可以应用到异常上面。当你在设计中添加一个异常类，一些基本的封装原则，像“不要做过多不必要的暴露”，肯定适用于异常。我能想到的还有一个问题是，限制异常类的构造器来控制使用对象得范围（框架还是客户？）：如果是框架内抛出，最好弄成包可见的构造器，这样可以保证客户端只有catch的能力；如果由客户抛出框架处理，最好限定异常的公共方法（getters）。

public final class UserException {
 
     @SuppressWarnings("unused")
 private int msg;
     /** Exception to signal result of execution of external process */
     private UserException(int e) { msg = e; }
     
     public static UserException exitCode(int msg) {
       return new UserException(msg);
     }
}

       另外，你可以用throw UserException.exitCode(404);的方式来抛出你的异常，只是工厂在带给你好处的同时也让你看起不太习惯罢了。你甚至可以final它给随后的扩展带来一些便利。总结一下就是说异常的设计也没有啥子不同。

分类

      一个逃不掉的话题--受检异常和运行时异常。从Java代码的层面这两者在可读性和维护性方面都是有区别的，但是从API进化的角度来讲有点相同也有不同..同：如果新版本抛出另外一种异常，两种异常都会不兼容  不同：一个是代码上就不兼容，另一个是功能上不兼容。

异常的设计

       这是我在上一个项目遇到的问题，当时我自作聪明包装了一个类似于IOException的方法，然后再抛出去。类似于：

  try {
ExceptionInitializer.init();
} catch (IOException e) {
throw new InnerWrapperEx(e);
}   

      后来层次做多了，一直不停上一层一层的trycatch。代码一片狼藉，其实回过头实在没有必要，真正起作用的就是IOException 为啥不直接从它扩展，然后来处理喃？！

处理异常

catch里面写啥？ 有谁敢说：“我没有写过空的catch块，也没有e.printStackTrace()过“？ 每本java教材都会叫你别写成这样。不处理的原因，最突出的一个就是基于这样一个误解”异常就是错就是bug 我的交付不允许有错“。推论就是 我处理了我就留下了我程序有错的证据。in my book 这个理论和做法是对的。 我的理论是”重要性决定处理方式！“ 而调用者决定重要性，因为调用者最清楚用例，他决定弹出信息或者写日志或者绕开返回，他当然可以觉得无所谓可以啥都不做。