|
|
 |
|
 |
继续讨论Exception的处理 |
热 ★★★ |
|
|
|
| 继续讨论Exception的处理 |
|
|
| 作者：佚名 文章来源：本站整理 更新时间：2008-7-18 17:08:28 |
|
|
|
继续讨论Exception的处理
简述
用Java在开发系统的时候，Exception的处理往往是比较复杂的。如何处理开发中遇到的Exception，如何将合理的异常信息呈现给客户是开发人员必须要考虑的问题。
关于Exception的处理的文章在很多地方都可以看到，本文除了做一个总结之外，还将结合Design by Contract，JDK 1.4引入的assertion，以及如何用Spring的AOP处理Exception做进一步的探讨。
Exception的分类
从JDK的API中我们可以看到，Java把异常分为了Error和Exception两大类，在Exception中又分为checked exception和runtime exception。从系统开发的角度上，我们可以把exception分为：
· JVM异常。这种异常我们不应该捕捉，因为它的出现意味着一些比较严重的错误，比如OutOfMemoryError，StackOverflowError等；
· 系统异常。大多数情况下，系统异常以RuntimeException的形式出现，比如NullPointerException, ArrayOutOfBoundsException等，这时往往意味着我们的程序里面出现了Bug；还有一种情况，例如我们没有办法通过JNDI找到某个资源，也应该属于系统异常。系统异常的主要特点是，当我们遇到这种异常的时候，我们没有合适的办法处理，或者说我们不能已一个合理的方式告诉最终用户系统出现了什么错误。很难想象用户看到一个NPE，并在界面上看到一堆stack trace是什么感觉。这种异常应该在单元测试以及集成测试的时候被检测到，在发布的时候应该尽可能不出现这样的问题；
· 应用异常。这种异常是由我们的系统。这些异常的出现对用户来说，可能是因为某个验证没有通过，某个操作的步骤出现错误等，比如插入数据库的时候出现主键重复的情况等。总之，这些异常的信息可以通过一个用户看的懂的方式显示给用户。
Design By Contract(DBC)
我们暂时把Exception的处理放在一边，先看看Design by Contract的概念。
对于任何一个软件系统来说，一个重要的目标就是可靠性，即正确性和健壮性。系统的正确性主要看这个系统是不是符合Specificat[1] [2] [3] [4] 下一页
|
|
|
|
| 文章录入：admin 责任编辑：admin |
|
|
上一篇文章： IntelliJ IDEA培训
下一篇文章： 今日笔记系列之Log4J |
|
|
|
|
|
|
|
|
|
|
|
|
