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