JVM 对 Java 异常的处理原理(try.catch 子句)

最初我们用 Java 写 JSP 的时候,几乎可以不触及异常,因为 Servlet 容器会把 API 抛出的异常包装成 ServletException 丢给容器去处理。再后来应用分层,代码中要处理的异常便多了,一般会转换成自定义的业务异常类,用 try-catch-throw customerException-finally。再到如今各种框架日臻成熟,代码中显式的异常处理又渐渐少了些,借助于 AOP 横行,异常对业务的影响描述被移入到了配置文件中了,例如,事物处理、权限的控制等。

这颇有些像手机的发展,当通信技术不甚发达的时候,手里抓的是砖头,信号是模拟的。后来慢慢瘦身成两三根手指大小,甚至是就一支笔似的,可如今信息量大了,屏幕要大,再配上 QWERT 键盘,机身自然就肥硕了。

当然与手机的个头变迁略有不同的是,任凭你怎么对待 Java 中异常,切入 AOP 也好,在 JVM 中处理异常的内在机制始终未变。 阅读全文 >>

类别: JVM. 标签: , , . 阅读(845). 评论(3) »

Unmi 学习 Groovy 之闭包与资源、异常处理

闭包还为我们提供了改善处理复杂 try/catch/finally 结构的方法。利用闭包,很容易编写正确处理资源和异常的代码。使用闭包的新方法已经添加到处理文件、进程和数据库连接的标准 Java 类中。当它们用在 Groovy 中的时候,不必处理和担心资源的关闭。首先我们来看看 Groovy 实现这一方式的原理。我们假设有这么一个资源处理类。

那么我们的打开、读取和关闭资源的典型的 Java 代码看起来就像这样: 阅读全文 >>

类别: Groovy. 标签: , . 阅读(179). 评论(4) »

使用Java的反射调用方法应注意的异常处理

先看下面的代码,看看程序执行会是什么样的结果:

简单分析上面的代码,代码中自定义了一个异常类,main调用了方法foo1,而方法foo1调用了方法foo2,在方法foo2中抛出的异常是MyException,该异常向上传播,在main方法中被catch,那么是不会会第一个catch语句捕获到,在控制台下打印出"Exception Type: MyException"呢?其实不然,异常会被第二个catch语句捕获,实际执行结果是"Exception Type: Exception"。

也就是尽管foo2方法中抛出的是MyException,但是让foo1通过反射方式调用后,异常被重新封装。从foo1方法中执向外面的异常实际是"InvocationTargetException",也就是执行method.invoke方法的异常了,那么在foo1中如何知道触发的实际异常呢,InvocationTargetException有一个方法getTargetException()可以获取到是MyException异常。

如果我们想在main方法中更细致的处理实际方法执行所抛出的异常,应如何做呢?我们可以改写foo1中的反射调用代码行

替换如下,让在foo2中触发的实际异常向外抛

这样的话,这个异常将在main方法的第一个catch块被捕获,异常类型被还原成MyException。

我是在项目中使用Struts,写了一个BaseAction,在BaseAction中根据参数反向调用相应的Action Perform方法时,在BaseAction中也是写成上面代码那样的异常捕获方式,结果发现只要是Action Perform方法中抛出的异常总是作为Exception被捕获的,而不能正确处理异常中描述的业务含业。

用Struts做项目时,经常会写自己的BaseAction,由这个BaseAction去分发执行哪一个实际方法,并且由它统一根据上抛的异常处理错误信息时就应该注意到这种问题。

类别: Java/JEE. 标签: , , . 阅读(607). 评论(0) »