java的异常处理机制

throws签名和catch clause，代码里有很多catch，方法签名也和异常绑定了。第三，有了更强的错误处理能力。如果发生了checked异常，我们有能力处理（修复）它。表现在不是任何错误都会导致程序挂起，出现了checked异常，程序可能照样运行。整个程序更加健壮，而代价就是前面2条。第二部分 使用checked异常的最佳实践现在假设有些错误我们确定为checked异常，那么我们针对这些checked异常要怎样编码才合理呢？1 不要用checked异常做流程控制。无论如何，checked异常也是一种错误。只是我们可以处理（修复）它而已。这种错误和普通业务流程还是有区别的，而且从效率上来说，用异常控制业务流程是不划算的。其实这个问题有时候很难界定，因为checked异常“可以修复”，那么就是说修复后程序照常运行，这样一来真的容易跟普通业务流程混淆不清。比如注册用户时用户名已经存在的问题。这个时候我们要考虑，为什么要用checked异常？这和使用业务流程相比，给我带来了什么好处？（注意checked异常可以修复，这是和unchecked异常本质的区别）照我的理解，checked异常应该是介于正常业务流程和unchecked异常（严重错误）之间的一种比较严重的错误。出现了这种错误，程序无法完成正常的功能是肯定的了，但我们可以通过其他方式弥补（甚至修复），总之不会让程序挂起就是。其实这一点也是设计checked异常时要考虑的问题，也是代价之一吧。2 对checked异常的封装。这里面包括2个问题：第一，如果要创建新的checked异常，尽量包含多一点信息，如果只是一条message，那么用Exception好了。当然，用Exception会失去异常的型别信息，让客户端无法判断具体型别，从而无法针对特定异常进行处理。第二，不要让你要抛出的checked exception升级到较高的层次。例如，不要让SQLException延伸到业务层。这样可以避免方法签名后有太多的throws。在业务层将持久层的所有异常统统归为业务层自定义的一种异常。3 客户端调用含有throws的方法要注意：第一，不要忽略异常。既然是checked异常，catch clause里理应做些有用的事情——修复它！catch里为空白或者仅仅打印出错信息都是不妥的！为空白就是假装不知道甚至瞒天过海，但是，出来混迟早要还的，迟早会报unchecked异常并程序挂起！非典就是个例子。打印出错信息也好不到哪里去，和空白相比除了多几行信息没啥区别。如果checked异常都被这么用，那真的不如当初都改成unchecked好了，大家都省事！第二，不要捕获顶层的Exception。你这么干，就是在犯罪！因为unchecked异常也是一种Exception！你把所有异常都捕获了——不是我不相信你的能力，你根本就不知道该如何处理！这样做的直接的后果就是，你的程序一般来说是不会挂起了，但是出现错误的时候功能废了，表面上却看不出什么！当然，深究起来，这也不是什么罪大恶极，如果你在catch里打印了信息，这和上面那条的情况是差不多的。而这2条的共同点就是，没有正确使用checked异常！费了那么大劲设计的checked异常就是给你们上级（客户端）用的，结果你们不会用！真的不如用unchecked干脆利落了！

关于 Java 中引入的 Checked Exceptions，目前存在着很多反对意见。正方的观点是引入 Checked Exceptions，可以增加程度的鲁棒性。反方的观点是 Checked Exceptions 很少被开发人员正确使用过，并且降低了程序开发的生产率和代码的执行效率。 正方代表 James Gosling http://www.artima.com/intv/solid.html 反方代表 Anders Hejlsberg http://www.artima.com/intv/csdes.html 中文版：http://www.csdn.net/develop/article/22/22612.shtm 我的一些观点：第一部分 选择checked or unchecked这里需要对异常的理解。什么算异常？java的异常处理机制是用来干什么的