浅析java异常处理机制—高级篇

定义和使用异常类

1、使用已有的异常类

例如IOException、SQLException。

try{ 
程序代码 
}catch(IOException ioe){ 
程序代码 
}catch(SQLException sqle){ 
程序代码 
}finally{ 
程序代码 
}

2、自定义异常类

创建Exception或者RuntimeException的子类即可得到一个自定义的异常类。例如:

public class UserException extends RuntimeException {
        public UserException() {
                super();
                // TODO Auto-generated constructor stub
        }

3、使用自定义的异常

用throws声明方法可能抛出自定义的异常，并用throw语句在适当的地方抛出自定义的异常。例如：在某种条件抛出异常

public void test1() throws UserException { 
... 
if(....){ 
throw new UserException (); 
} 
}

将异常转型(也叫转译)，使得异常更易读易于理解

public void test2() throws UserException { 
... 
try{ 
... 
}catch(SQLException e){ 
... 
throw new UserException (); 
} 
}

还有一个代码，很有意思：

public void test2() throws MyException{ 
... 
try { 
... 
} catch (MyException e) { 
throw e; 
} 
}

这段代码实际上捕获了异常，然后又和盘托出，没有一点意义，如果这样还有什么好处理的，不处理就行了，直接在方法前用throws声明抛出不就得了。异常的捕获就要做一些有意义的处理。

JAVA异常处理中的注意事项

合理使用JAVA异常机制可以使程序健壮而清晰，但不幸的是，JAVA异常处理机制常常被错误的使用，下面就是一些关于Exception的注意事项：

1． 不要忽略checked Exception

请看下面的代码：

try
{
  method1();  //method1抛出ExceptionA
}
catch(ExceptionA e)
{
    e.printStackTrace();
}

上面的代码似乎没有什么问题，捕获异常后将异常打印，然后继续执行。事实上在catch块中对发生的异常情况并没有作任何处理(打印异常不能是算是处理异常，因为在程序交付运行后调试信息就没有什么用处了)。这样程序虽然能够继续执行，但是由于这里的操作已经发生异常，将会导致以后的操作并不能按照预期的情况发展下去，可能导致两个结果：
一、是由于这里的异常导致在程序中别的地方抛出一个异常，这种情况会使程序员在调试时感到迷惑，因为新的异常抛出的地方并不是程序真正发生问题的地方，也不是发生问题的真正原因；
二、程序继续运行，并得出一个错误的输出结果，这种问题更加难以捕捉，因为很可能把它当成一个正确的输出。
那么应该如何处理呢，这里有四个选择：

1. 处理异常，进行修复以让程序继续执行。

2. 重新抛出异常，在对异常进行分析后发现这里不能处理它，那么重新抛出异常，让调用者处理。

3. 将异常转换为用户可以理解的自定义异常再抛出，这时应该注意不要丢失原始异常信息。
4. 不要捕获异常。

因此，当捕获一个unchecked Exception的时候，必须对异常进行处理；如果认为不必要在这里作处理，就不要捕获该异常，在方法体中声明方法抛出异常，由上层调用者来处理该异常。

2． 不要一次捕获所有的异常

请看下面的代码：

try
{
  method1();  //method1抛出ExceptionA
    method2();  //method1抛出ExceptionB
    method3();  //method1抛出ExceptionC
}
catch(Exception e)
{
    ……
}

这是一个很诱人的方案，代码中使用一个catch子句捕获了所有异常，看上去完美而且简洁，事实上很多代码也是这样写的。但这里有两个潜在的缺陷，一是针对try块中抛出的每种Exception，很可能需要不同的处理和恢复措施，而由于这里只有一个catch块，分别处理就不能实现。二是try块中还可能抛出RuntimeException,代码中捕获了所有可能抛出的RuntimeException而没有作任何处理，掩盖了编程的错误，会导致程序难以调试。
下面是改正后的正确代码：

try
{
  method1();  //method1抛出ExceptionA
    method2();  //method1抛出ExceptionB
    method3();  //method1抛出ExceptionC
}
catch(ExceptionA e)
{
    ……
}
catch(ExceptionB e)
{
    ……
}
catch(ExceptionC e)
{
    ……
}

3． 异常不能影响对象的状态

异常产生后不能影响对象的状态，这是异常处理中的一条重要规则。 在一个函数
中发生异常后，对象的状态应该和调用这个函数之前保持一致，以确保对象处于正确的状态中。
如果对象是不可变对象(不可变对象指调用构造函数创建后就不能改变的对象，即
创建后没有任何方法可以改变对象的状态)，那么异常发生后对象状态肯定不会改变。如果是可变对象，必须在编程中注意保证异常不会影响对象状态。有三个方法可以达到这个目的：
1. 将可能产生异常的代码和改变对象状态的代码分开，先执行可能产生异常的代码，如果产生异常，就不执行改变对象状态的代码。
2. 对不容易分离产生异常代码和改变对象状态代码的方法，定义一个recover方法，在异常产生后调用recover方法修复被改变的类变量，恢复方法调用前的类状态。
3. 在方法中使用对象的拷贝，这样当异常发生后，被影响的只是拷贝，对象本身不会受到影响。

4． 丢失的异常

请看下面的代码：

public void method2()
{
try
{
    ……
    method1();  //method1进行了数据库操作
}
catch(SQLException e)
{
    ……
    throw new MyException(“发生了数据库异常:”+e.getMessage);
}
}
public void method3()
{
    try
{
    method2();
}
catch(MyException e)
{
    e.printStackTrace();
    ……
}
}

上面method2的代码中，try块捕获method1抛出的数据库异常SQLException后，抛出了新的自定义异常MyException。这段代码是否并没有什么问题，但看一下控制台的输出：

MyException:发生了数据库异常：对象名称 ‘MyTable’ 无效。
at MyClass.method2(MyClass.java:232)
at MyClass.method3(MyClass.java:255)

原始异常SQLException的信息丢失了，这里只能看到method2里面定义的MyException的堆栈情况；而method1中发生的数据库异常的堆栈则看不到，如何排错呢，只有在method1的代码行中一行行去寻找数据库操作语句了，祈祷method1的方法体短一些吧。

5． 不要使用同时使用异常机制和返回值来进行异常处理

下面是我们项目中的一段代码

try
{
    doSomething(); 
}
catch(MyException e)
{
if(e.getErrcode == -1)
{
    ……
}
if(e.getErrcode == -2)
{
   ……
}
……
}

假如在过一段时间后来看这段代码，你能弄明白是什么意思吗？混合使用JAVA异常处理机制和返回值使程序的异常处理部分变得“丑陋不堪”，并难以理解。如果有多种不同的异常情况，就定义多种不同的异常，而不要像上面代码那样综合使用Exception和返回值。
修改后的正确代码如下：

try
{
    doSomething();  //抛出MyExceptionA和MyExceptionB
}
catch(MyExceptionA e)
{
……
}
catch(MyExceptionB e)
{
    ……
}

6． 不要让try块过于庞大

出于省事的目的，很多人习惯于用一个庞大的try块包含所有可能产生异常的代码，这样有两个坏处：
1. 阅读代码的时候，在try块冗长的代码中，不容易知道到底是哪些代码会抛出哪些异常，不利于代码维护。
2. 使用try捕获异常是以程序执行效率为代价的，将不需要捕获异常的代码包含在try块中，影响了代码执行的效率。

总结

对java异常从宏观到应用我们有了一个简单的了解，那么在写代码的时候要对异常进行正确的处理，规避一些错误和麻烦，让我们的系统更加健壮和优美。再次强调一下，编写程序时，人性化的日志输出事非常必要的。