JAVA 技术文章收集(10)

常，编译器就通不过，不允许编译。

非检测异常

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

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

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

自定义异常

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

5、 Java 异常处理的原则和忌讳

Java 异常处理的原则

1 尽可能的处理异常

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

2 具体问题具体解决

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

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

至少要采取一些永久的方式，记录下可能影响应用程序操作的异常。理想情况下，当然是在第一时间解决引发异常的基本问题。不过，无论采用哪种处理操作，一般总应记录下潜

在的关键问题。别看这个操作很简单，但它可以帮助您用很少的时间来跟踪应用程序中复杂问题的起因。

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

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

1 一般不要忽略异常

在异常处理块中，一项最危险的举动是“不加通告”地处理异常。如下例所示： 1 try{ 2 Class.forName(\3 } 4 catch (ClassNotFoundException exc){} 经常能够在代码块中看到类似的代码块。有人总喜欢在编写代码时简单快速地编写空处理器块，并“自我安慰地”宣称准备在“后期”添加恢复代码，但这个“后期”变成了“无期”。

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

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

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

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

另一个危险的处理是覆盖式处理器（blanket handler）。该代码的基本结构如下： 1 try{ 2 // ? 3 } 4 catch(Exception e){ 5 // ? 6 } 使用覆盖式异常处理块有两个前提之一：

1 代码中只有一类问题。

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

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

这几乎绝对错误。几乎没有哪个方法能放之四海而皆准，能应对出现的任何问题。 分析下这样编写代码将发生的情况。只要方法不断抛出预期的异常集，则一切正常。但是，如果抛出了未预料到的异常，则无法看到要采取的操作。当覆盖式处理器对新异常类执行千篇一律的任务时，只能间接看到异常的处理结果。如果代码没有打印或记录语句，则根本看不到结果。

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

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

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

1 try{ 2 // Error-prone code 3 } 4 catch(IOException e){ 5 String msg = \ 6 throw new Exception(msg); 7 } 因为没有原始异常的信息，所以处理器块无法确定问题的起因，也不知道如何更正问题。 不要处理能够避免的异常

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

6、 Java 异常处理的应用实例

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

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

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

级方法调用。 异常类：

class InsufficientFundsExceptionextends Exception{ private Bank excepbank; // 银行对象 private double excepAmount; // 要取的钱 InsufficientFundsException(Bank ba, double dAmount) { excepbank=ba; excepAmount=dAmount; } public String excepMessage(){ String str=\ + \ return str; } }// 异常类 银行类：

class Bank{ double balance;// 存款数 Bank(double balance){this.balance=balance;} public void deposite(double dAmount){ if(dAmount>0.0) balance+=dAmount; } public void withdrawal(double dAmount) throws InsufficientFundsException{ if (balance

public class ExceptionDemo{ public static void main(String args[]){ try{ Bank ba=new Bank(50); ba.withdrawal(100); System.out.println(\ }catch(InsufficientFundsException e) { System.out.println(e.toString()); System.out.prin …… 此处隐藏：2727字，全部文档内容请下载后查看。喜欢就下载吧 ……