ITPub博客

首页 > 大数据 > Hadoop > java中异常处理原理及应用(2)

java中异常处理原理及应用(2)

Hadoop 作者:jlin_lin 时间:2013-09-24 16:15:00 0 删除 编辑

Java
异常的处理

 
  在 Java 应用程序中,对异常的处理有两种方式:处理异常和声明异常。

 
  处理异常:try、catch 和 finally

 
  若要捕获异常,则必须在代码中添加异常处理器块。这种 Java 结构可能包含 3 个部分,

 
  都有 Java 关键字。下面的例子中使用了 try-catch-finally 代码结构。

 
  import java.io.*; public class EchoInputTryCatchFinally { public static void
main(String args[]){ System.out.println(”Enter text to echo:”);
InputStreamReader isr = new InputStreamReader(System.in); BufferedReader
inputReader = new BufferedReader(isr); try{ String inputLine =
inputReader.readLine(); System.out.println(”Read:” + inputLine); }
catch(IOException exc){ System.out.println(”Exception encountered: ” + exc); }
finally{ System.out.println(”End. “); } } 其中:

 
  try 块:将一个或者多个语句放入 try 时,则表示这些语句可能抛出异常。编译器知道可能要发生异常,于是用一个特殊结构评估块内所有语句。

 
  catch 块:当问题出现时,一种选择是定义代码块来处理问题,catch 块的目的便在于此。catch 块是 try
块所产生异常的接收者。基本原理是:一旦生成异常,则 try 块的执行中止,JVM 将查找相应的 JVM。

 
  finally 块:还可以定义 finally 块,无论运行 try 块代码的结果如何,该块里面的代码一定运行。在常见的所有环境中,finally
块都将运行。无论 try 块是否运行完,无论是否产生异常,也无论是否在 catch 块中得到处理,finally 块都将执行。

 
  try-catch-finally 规则:

 
  必须在 try 之后添加 catch 或 finally 块。try 块后可同时接 catch 和 finally 块,但至少有一个块。

 
  必须遵循块顺序:若代码同时使用 catch 和 finally 块,则必须将 catch 块放在 try 块之后。

 
  catch 块与相应的异常类的类型相关。

 
  一个 try 块可能有多个 catch 块。若如此,则执行第一个匹配块。

 
  可嵌套 try-catch-finally 结构。

 
  在 try-catch-finally 结构中,可重新抛出异常。

 
  除了下列情况,总将执行 finally 做为结束:JVM 过早终止(调用 System.exit(int));在 finally
块中抛出一个未处理的异常;计算机断电、失火、或遭遇病毒攻击。

 
  声明异常

 
  若要声明异常,则必须将其添加到方法签名块的结束位置。下面是一个实例:

 
  public void errorProneMethod(int input) throws java.io.IOException { //Code
for the method,including one or more method //calls that may produce an
IOException } 这样,声明的异常将传给方法调用者,而且也通知了编译器:该方法的任何调用者必须遵守处理或声明规则。声明异常的规则如下:

 
  必须声明方法可抛出的任何可检测异常(checked exception)。

 
  非检测性异常(unchecked exception)不是必须的,可声明,也可不声明。

 
 
调用方法必须遵循任何可检测异常的处理和声明规则。若覆盖一个方法,则不能声明与覆盖方法不同的异常。声明的任何异常必须是被覆盖方法所声明异常的同类或子类。

 
  Java 异常处理的分类

 
  Java 异常可分为可检测异常,非检测异常和自定义异常。

 
  可检测异常

 
  可检测异常经编译器验证,对于声明抛出异常的任何方法,编译器将强制执行处理或声明规则,例如:sqlExecption 这个异常就是一个检测异常。你连接
JDBC 时,不捕捉这个异常,编译器就通不过,不允许编译。

非检测异常

 
  非检测异常不遵循处理或声明规则。在产生此类异常时,不一定非要采取任何适当操作,编译器不会检查是否已解决了这样一个异常。例如:一个数组为 3
个长度,当你使用下标为3时,就会产生数组下标越界异常。这个异常 JVM
不会进行检测,要靠程序员来判断。有两个主要类定义非检测异常:RuntimeException 和 Error。

 
  Error 子类属于非检测异常,因为无法预知它们的产生时间。若 Java 应用程序内存不足,则随时可能出现
OutOfMemoryError;起因一般不是应用程序的特殊调用,而是 JVM 自身的问题。另外,Error 一般表示应用程序无法解决的严重问题。

 
  RuntimeException 类也属于非检测异常,因为普通 JVM 操作引发的运行时异常随时可能发生,此类异常一般是由特定操作引发。但这些操作在
Java 应用程序中会频繁出现。因此,它们不受编译器检查与处理或声明规则的限制。

 
  自定义异常

 
 
自定义异常是为了表示应用程序的一些错误类型,为代码可能发生的一个或多个问题提供新含义。可以显示代码多个位置之间的错误的相似性,也可以区分代码运行时可能出现的相似问题的一个或者多个错误,或给出应用程序中一组错误的特定含义。例如,对队列进行操作时,有可能出现两种情况:空队列时试图删除一个元素;满队列时试图添加一个元素。则需要自定义两个异常来处理这两种情况。

 
  Java 异常处理的原则和忌讳

 
  Java 异常处理的原则

 
  尽可能的处理异常

 
 
要尽可能的处理异常,如果条件确实不允许,无法在自己的代码中完成处理,就考虑声明异常。如果人为避免在代码中处理异常,仅作声明,则是一种错误和依赖的实践。

 
  具体问题具体解决

 
 
异常的部分优点在于能为不同类型的问题提供不同的处理操作。有效异常处理的关键是识别特定故障场景,并开发解决此场景的特定相应行为。为了充分利用异常处理能力,需要为特定类型的问题构建特定的处理器块。

 
  记录可能影响应用程序运行的异常

 
 
至少要采取一些永久的方式,记录下可能影响应用程序操作的异常。理想情况下,当然是在第一时间解决引发异常的基本问题。不过,无论采用哪种处理操作,一般总应记录下潜在的关键问题。别看这个操作很简单,但它可以帮助您用很少的时间来跟踪应用程序中复杂问题的起因。

 
  根据情形将异常转化为业务上下文

 
 
若要通知一个应用程序特有的问题,有必要将应用程序转换为不同形式。若用业务特定状态表示异常,则代码更易维护。从某种意义上讲,无论何时将异常传到不同上下文(即另一技术层),都应将异常转换为对新上下文有意义的形式。

 
  Java 异常处理的忌讳

 
  一般不要忽略异常

 
  在异常处理块中,一项最危险的举动是“不加通告”地处理异常。如下例所示:

 
  try{ Class.forName(”business.domain.Customer”); } catch
(ClassNotFoundException exc){}
经常能够在代码块中看到类似的代码块。有人总喜欢在编写代码时简单快速地编写空处理器块,并“自我安慰地”宣称准备在“后期”添加恢复代码,但这个“后期”变成了“无期”。

 
 
这种做法有什么坏处?如果异常对应用程序的其他部分确实没有任何负面影响,这未尝不可。但事实往往并非如此,异常会扰乱应用程序的状态。此时,这样的代码无异于掩耳盗铃。

 
  这种做法若影响较轻,则应用程序可能出现怪异行为。例如,应用程序设置的一个值不见了, 或 GUI
失效。若问题严重,则应用程序可能会出现重大问题,因为异常未记录原始故障点,难以处理,如重复的 NullPointerExceptions。

 
 
如果采取措施,记录了捕获的异常,则不可能遇到这个问题。实际上,除非确认异常对代码其余部分绝无影响,至少也要作记录。进一步讲,永远不要忽略问题;否则,风险很大,在后期会引发难以预料的后果。

 
  不要使用覆盖式异常处理块

 
  另一个危险的处理是覆盖式处理器(blanket handler)。该代码的基本结构如下:

 
  try{ // … } catch(Exception e){ // … } 使用覆盖式异常处理块有两个前提之一:

 
  1. 代码中只有一类问题。

 
  这可能正确,但即便如此,也不应使用覆盖式异常处理,捕获更具体的异常形式有利物弊。

 
  2. 单个恢复操作始终适用。

 
  这几乎绝对错误。几乎没有哪个方法能放之四海而皆准,能应对出现的任何问题。

 
 
分析下这样编写代码将发生的情况。只要方法不断抛出预期的异常集,则一切正常。但是,如果抛出了未预料到的异常,则无法看到要采取的操作。当覆盖式处理器对新异常类执行千篇一律的任务时,只能间接看到异常的处理结果。如果代码没有打印或记录语句,则根本看不到结果。

 
  更糟糕的是,当代码发生变化时,覆盖式处理器将继续作用于所有新异常类型,并以相同方式处理所有类型。

 
  一般不要把特定的异常转化为更通用的异常

 
  将特定的异常转换为更通用异常时一种错误做法。一般而言,这将取消异常起初抛出时产生的上下文,在将异常传到系统的其他位置时,将更难处理。见下例:

 
  try{ // Error-prone code } catch(IOException e){ String msg = “If you didn ’ t
have a problem before,you do now!”; throw new Exception(msg); }
因为没有原始异常的信息,所以处理器块无法确定问题的起因,也不知道如何更正问题。

 
  不要处理能够避免的异常

 
  对于有些异常类型,实际上根本不必处理。通常运行时异常属于此类范畴。在处理空指针或者数据索引等问题时,不必求助于异常处理。

 
  Java 异常处理的应用实例

 
  在定义银行类时,若取钱数大于余额时需要做异常处理。

 
  定义一个异常类 insufficientFundsException。取钱(withdrawal)方法中可能产生异常,条件是余额小于取额。

 
  处理异常在调用 withdrawal 的时候,因此 withdrawal 方法要声明抛出异常,由上一级方法调用。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/21986345/viewspace-1111542/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 没有了~
下一篇: 没有了~
请登录后发表评论 登录
全部评论

注册时间:2009-06-27