异常的处理（转）

e.printStackTrace();这条语句如果程序中用的比较多的话，那就说明你是个吞异常的高手。然而很遗憾， 成为了吞异常的高手，就一定是一个处理异常的低手(这个词太别扭了，改用'菜鸟'吧)！如果把不该吞的异常也给吞了，那就降低了程序和用户(包括二次开发 人员、测试人员以及普通用户)之间的交互性。

程序如果在出错的时候总是保持沉默，那用户不爽的次数到达一定数量后，最终将极有可能把我们所谓的作品给抛 弃。异常处理的重要性已经体现出来了，要不然SUN公司也不会专门搞个异常处理机制了。

说到这里，真正需要思考的问题才刚刚开始，如何才能更好地或者说更 为合理地进行异常的处理呢？要想成为异常处理的高手，首先肯定得了解产生异常的原因，然后根据原因进行相应处理。究竟是抛，还是不抛(或者说'吞')，这 是一个问题；究竟是使用默认异常还是自定义异常，这同样也是一个问题。如果异常是系统内部引起并且是我们能够确定的，比如说一个字符串s在使用 getBytes("UTF-8")时出现UnsupportedEncodingException异常，那么就可以把它吞了(或者抛出一个 Error)，因为UTF-8是系统支持的基本编码集之一；如果异常是我们无法确定的，那此时就应该向上抛出，比如我们在写一个底层函数，需要进行文件的 读写操作，那么很显然会有一个FileNotFoundException异常，这时就应该抛出去；但是如果我们站在更上一层，能够直接面向用户了，这时 就得进行异常处理，比如来个信息提示说相应的文件没找到。

接着说说自定义异常给我们带来的好处。自定义异常的好处个人认为主要有两点：一是能够更好的进行 异常定位；二是能够将同种性质或是类似性质的异常进行归类，向上抛出后方便别人处理。比如给别人提供了一个二次开发函数，作用是读取一个Xml格式的文 件，并且通过一系列解密操作，得到原始信息，然后通过这些信息进行相关类的构造。既然是读取文件，那么必然会有一个 FileNotFoundException异常，又由于是一个经过加密的xml文件，那么在读取操作时也很有可能会产生诸如xml文件格式不正确、 xml节点错误、xml节点内容错误等各种异常情况。对于二次开发人员来说FileNotFoundException异常很方便处理，但后面的几种异常 可能会使他产生厌烦。此时，我们就应该使用自定义异常将xml文件格式不正确、xml节点错误、xml节点内容错误等各种异常归并起来，然后向上抛出。于 是对于二次开发人员来说，他只需要处理两个异常，一个是FileNotFoundException，另一个则是我们自定义的异常，比如 FileContentInvalidException(文件内容无效)异常。因为产生文件内容无效的原因，多半是由于正确产生出的xml文件被非法修 改过所造成的。当然了，自定义异常的名称最好也能够见名知意！

个人观点：在适当的时候抛出包装了的异常，会给人带来更大的人机交互功能，也能让人觉得所写的代码不再死板，而是一个貌似有血有肉的活物。这样的程序不仅客户看着舒服，自己也会觉得很爽。