欢迎进入Java社区论坛，与200万技术人员互动交流 >>进入
3、 如果要调用传入的参数的某个方法，一定要Null检查。或者该信息必不可少。
如果不进行null检查，虚拟机也会帮你自动抛出runtime的NEP错误。所以，很多人并不在意这件事情。如果你的方法会被别人调用，且别人看不到你的方法代码，那问题就大了。
static void f(String str){
System.out.println(str.length());
}
public static void main(String[] args) {
f(null);
}
如上图的代码，抛出的异常信息显示，f方法中的第9行出现了NPE。但是，很可能别人调用你的代码时是已经编译过的class。在这种情况下，调用者就很难发现问题。所以，一定要进行异常检查，抛出一个新的并带有相关的提示信息。开源框架的代码都会进行这样的检查，如jdbcTemplate的某个方法，通过Assert.notNull对action进行了相关检查，如果为null抛出runtime异常。
4、 检查异常与非检查异常
Java的异常结构体系如下所示：
其中的RuntimeException及其子类异常时非检查异常。在编程时不强制你显示处理。如果一个异常是致命的且不可恢复并且对于捕获该异常的方法根本不知如何处理时，或者捕获这类异常无任何益处，通常应该定义这类异常为非检查异常，由顶层专门的异常处理程序处理;像数据库连接错误、网络连接错误或者文件打不开等之类的异常一般均属于非检查异常。这类异常一般与外部环境相关，一旦出现，基本无法有效地处理。
Spring Dao选择了把所有SQLException转换成了DataAccessException异常，是runtime的。这样，编程的代结构和可读性有了巨大的提升。如数据库关闭异常的，甚至直接catch并记录相关过程，连异常也不抛出。
而对于一些具备可以回避异常或预料内可以恢复并存在相应的处理方法的异常，可以定义该类异常为检查异常。像一般由输入不合法数据引起的异常或者与业务相关的一些异常，基本上属于检查异常。当出现这类异常，一般可以经过有效处理或通过重试可以恢复正常状态。
5、 异常视角
使用者不应该接触Java异常，程序不应该在没有提示的情况下突然崩溃。Java像现在应用比较广泛的地方应是web方面。Tomcat之类的web容器能够很好的处理异常，一般情况内部的逻辑错误不会造成应用的崩溃。异常信息也会在前端页面显示，在开发阶段或者内部测试期间应该直接暴露异常信息至前端，这样有利于报告错误。正式发布阶段，应该将500等错误直接跳转至专门的页面。
6、 catch异常后冲洗throw异常，应该包含异常链
异常链对于程序调试尤为关键。异常链的保留可以追溯异常源，这样有利于异常的正确和及时定位。异常链的丢失，有的时候绝对是致命的。
[1][2]
不要因为世态变迁而埋怨,不要因为命运多舛而怨恨.
