最初我们用 Java 写 JSP 的时候，几乎可以不触及异常，因为 Servlet 容器会把 API 抛出的异常包装成 ServletException 丢给容器去处理。再后来应用分层，代码中要处理的异常便多了，一般会转换成自定义的业务异常类，用 try-catch-throw customerException-finally。再到如今各种框架日臻成熟，代码中显式的异常处理又渐渐少了些，借助于 AOP 横行，异常对业务的影响描述被移入到了配置文件中了，例如，事物处理、权限的控制等。
这颇有些像手机的发展，当通信技术不甚发达的时候，手里抓的是砖头，信号是模拟的。后来慢慢瘦身成两三根手指大小，甚至是就一支笔似的，可如今信息量大了，屏幕要大，再配上 QWERT 键盘，机身自然就肥硕了。
当然与手机的个头变迁略有不同的是，任凭你怎么对待 Java 中异常，切入 AOP 也好，在 JVM 中处理异常的内在机制始终未变。 阅读全文 >>
闭包还为我们提供了改善处理复杂 try/catch/finally 结构的方法。利用闭包，很容易编写正确处理资源和异常的代码。使用闭包的新方法已经添加到处理文件、进程和数据库连接的标准 Java 类中。当它们用在 Groovy 中的时候，不必处理和担心资源的关闭。首先我们来看看 Groovy 实现这一方式的原理。我们假设有这么一个资源处理类。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
class Resource{ public Resource(String resourceName) throws ResourceException{ //open the resource } public Object read() throws ResourceException{ //return data or false as the end marker } public void close() throws ResourceException{ //close the resource } } |
那么我们的打开、读取和关闭资源的典型的 Java 代码看起来就像这样： 阅读全文 >>
先看下面的代码，看看程序执行会是什么样的结果：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
import java.lang.reflect.Method; /** * @author Unmi */ public class ExceptionTest { public static void main(String[] args) { try{ foo1(); }catch (MyException me) { System.out.println(“Exception Type: MyException”); }catch (Exception e) { System.out.println(“Exception Type: Exception”); } } public static void foo1() throws Exception{ Method method = ExceptionTest.class.getDeclaredMethod(“foo2″,new Class[]{}); //注意调用foo2时，foo2方法会抛出MyException异常 method.invoke(null,new Object[]{}); }<!--more--> public static void foo2() throws Exception{ throw new MyException(); //foo2方法直接抛出异常 } } //一个自定义的异常 class MyException extends Exception{ } |