Java 异常机制

Java 异常分为检查异常和非检查异常，所有RuntimeException的子类都是非检查异常，其他异常为检查异常，如下图所示：

image

Java程序必须显示处理检查异常：当前方法知道如何处理该异常，则用try...catch块来处理该异常，否则需要在方法定义时使用throws关键字声明抛出该异常。Java程序无须显式的处理非检查异常，这类异常通常交由缺省的异常处理代码处理，通常非检查异常都和编码错误有关。

本文主要参考了 "Effective Java"一书中关于异常处理的章节，并结合AOSP 电子邮件应用源码， 总结了异常处理的一些规则。

选择合适的异常

检查异常通常用于可以恢复的场景，如网络错误。在Email登陆的代码中，如果用户名密码有误，则会抛出一个检查异常，上层代码捕获到这个异常后，可以增加相应提示，用户可根据提示检查输入。相关代码如下：

@Override
public synchronized void open(OpenMode mode) throws MessagingException {
    try {
        executeSensitiveCommand("USER " + mUsername, "USER /redacted/");
        executeSensitiveCommand("PASS " + mPassword, "PASS /redacted/");
    } catch (MessagingException me) {
        if (DebugUtils.DEBUG) {
            LogUtils.d(Logging.LOG_TAG, me.toString());
        }
        throw new AuthenticationFailedException(null, me);
    }
}

非检查异常，通常用于编码错误，这类异常发生后，通常没有好的办法恢复到执行前的状态。Email本地执行本地搜索功能可选择标题，正文，发件人，收件人，以及全部五种搜索方式，代码中搜索方式以一个整形表示。用于本地搜索的接口会检查输入的搜索方式，如果输入了未定义的搜索方式，则抛出IllegalArgumentException，相关代码如下:

private Cursor uiLocalSearch(Uri uri, String[] projection, boolean unseenOnly){
    if ((approach & SearchParams.SEARCH_BY_RECIVER) == 0
        && (approach & SearchParams.SEARCH_BY_SENDER) == 0
        && (approach & SearchParams.SEARCH_BY_SUBJECT) == 0
        && (approach & SearchParams.SEARCH_BY_CONTENT) == 0) {
        throw new IllegalArgumentException("Invalid search approach: " + approach + " in search query");
    }
}

JDK中定义了很多标准的异常，使用这类异常可以便于维护代码的同事理解：

Exception	Usage
IllegalArgumentException	输入参数不合法
IllegalStateException	调用方法时对象状态有误，如未初始化
NullPointerExceptio	输入了空的参数（参数不允许为空）
IndexOutOfBoundsException	输入的Index值超出范围
UnsupportedOperationException	尚未实现的功能被错误调用

仅异常情况下使用异常

Java异常机制主要用于处理异常情况和编码错误，不应该作业务逻辑实现的手段。下面的代码使用异常处理检查空指针，编码中应该要尽量避免这种写法,例如下面这段代码：

//不推荐的写法，应尽量避免
String uriAddress = getRingtoneAddressFromUri(context, uri);
if (uriAddress != null) {
    try {
        File file = new File(uriAddress.toString());
        if(file.exists()) {
            return false;
        } else {
            return true;
        }
    } catch (NullPointerException e) {
        return true;
    }
} else {
    return true;
}

上面的代码缺陷如下：

• 包含在try…catch内的代码块通常情况执行相对较慢
• 由于捕获了NullPointerException, try…catch调用的接口实现中如果包含空指针相关的编码错误，会被一并捕获而不是出现Java Crash，造成问题调试困难
• 代码冗长，难以理解

可以将上述代码重构为：

String uriAddress = getRingtoneAddressFromUri(context, uri);
File file = (uriAddress == null) ? null : new File(uriAddress.toString());
return file == null || !file.exists();

• 不要忽略异常
  忽略异常平常代码中很常见，最常见的一种写法就是将代码包含在try…catch模块中，并且catch部分留空:

//不推荐的写法，应尽量避免
try {
    // do something
} catch (SomeException e) {
    // do nothing
}

忽略代码最直接的影响就是调试Bug的时候非常困难，尤其是偶现问题。Email原生代码在保存附件时，有如下代码:

//不推荐的写法，应尽量避免
public static String saveAttachment(Context context, InputStream in, Attachment attachment,final boolean updateDb) {
    // do something
    try {
        File file = Utility.createUniqueFile(downloads, attachment.mFileName);
        // do something
    } catch (IOException e) {
       cv.put(AttachmentColumns.UI_STATE,UIProvider.AttachmentState.FAILED);
    }
  // do something 
}

捕获了IOException又未作任何处理。当由于try 中的代码抛出IOException，导致Bug时，无法从LOG中定位错误原因。InputStream和OutputSream的关闭操作通常可以忽略抛出的IOException，一般情况下并不会带来负面的影响。在大多数情况下都不应该忽略异常，建议至少增加一条包含调用栈的打印。

• 避免抛出不必要的检查异常
  由于Java程序必须显示处理检查异常，如果函数定义时声明了抛出非检查异常，所有调用这个函数的地方都需要将异常继续抛出或者处理这个异常。一方面这种机制可以强制工程师在使用接口时处理异常，另一方面也会增加接口使用者的负担，尤其是当一个方法早期版本不抛出异常，一次修改后增加了异常抛出，此时需要在之前所有调用的地方增加异常捕获代码。Email中用于获得DeviceId的函数声明抛出IOException就很好的污染了代码。接口定义如下：

//不推荐的写法，应尽量避免
static public synchronized String getDeviceId(Context context) throws IOException {
    if (sDeviceId == null) {
        sDeviceId = getDeviceIdInternal(context);
    }
    return sDeviceId;
}

在整个代码中，有多个地方调用到了这个接口，这些代码基本上如下：

try {
    return Device.getDeviceId(mContext);
} catch (IOException e) {
    return null;
}

try {
    deviceId = Device.getDeviceId(getActivity());
} catch (IOException e) {
    // Not required
}

可以看出来，这些调用基本是无意义的。通常来说一个方法是否有必要抛出检查异常可以判断下面两个条件：

• 异常情况是否可以通过合理使用方法来避免，比如增加测试方法是否可行的接口
• 在方法内部是否可以合理的处理发生的异常

基于上述两点，getDeviceId可以重构如下：

//1 增加 测试接口
static public synchronized boolean isDeviceIdReady() {
    //return true or false
}
//使用API时 ：
String deviceId = isDeviceIdReady(): Device.getDeviceId() : null；
//2 方法内部处理异常
static public synchronized String getDeviceId(Context context) {
    if (sDeviceId == null) {
        try {
            sDeviceId = getDeviceIdInternal(context);
        } catch (IOException e) {
            if (DEBUG) {
                Log.d("Email", "IOException while getDeviceId", e);
            }
            return "";
        }
    }
    return sDeviceId;
}

不要捕获所有异常

有时调用的一个方法会检测抛出多个异常，为了代码简洁，会捕获所有异常，如下述代码：

//不推荐的写法，应尽量避免
try {
    // do someting that might throw IOException
    // do someting that might throw CertificateException
} catch (Exception e) {

}

这样些会可能带来一些问题：

• 调用的接口的潜在Bug被忽略
• 不同类型的异常可能需要不同的处理

上面的代码可以更改为：

try {
    // do someting that might throw IOException
    // do someting that might throw CertificateException
} catch (IOException e) {
    // Do something handle IOException
} catch (CertificateException e) {
    // Do something handle CertificateException
}

如果所有异常处理方式一致，且JDK版本高于1.7，可以简化如下：

try {
    // do someting that might throw IOException
    // do someting that might throw CertificateException
} catch (IOException | CertificateException e) {
    // Do something handle these exception
}

根据业务逻辑抽象异常

有时某些函数抛出异常和业务代码的关系并不明确或是相同业务逻辑下需要处理不同的异常，这时可以通过“异常翻译”的方法，将这类异常抽象成和业务代码相关的异常。
以Email登陆认证为例，Email登陆不同协议时和服务器的交互方法差别很大，Pop3/Imap协议采用了Socket，Exchange协议使用的是http，各协议下都可能使用SSL, Exchange网络交互的代码和用户界面的代码分别运行在不同进程等等。为了减少用户界面代码和具体协议之间的耦合，不同协议的登陆代码都进行了必要的“异常翻译”.

IMAP登陆代码如下:

public Bundle checkSettings() throws MessagingException {
    int result = MessagingException.NO_ERROR;
    Bundle bundle = new Bundle();
    ImapConnection connection = new ImapConnection(this);
    try {
        connection.open();
        connection.close();
    } catch (IOException ioe) {
        bundle.putString(EmailServiceProxy.VALIDATE_BUNDLE_ERROR_MESSAGE, ioe.getMessage());
        result = MessagingException.IOERROR;
    } finally {
        connection.destroyResponses();
    }
    bundle.putInt(EmailServiceProxy.VALIDATE_BUNDLE_RESULT_CODE, result);
    return bundle;
}

void open() throws IOException, MessagingException {
    try {
        //excute connection.open();
    } catch (SSLException e) {
        //class CertificateValidationException extends MessagingException
        throw new CertificateValidationException(e.getMessage(), e);
    } catch (IOException ioe) {
        throw ioe;
    } finally {
        destroyResponses();
    }
}

上面的代码中，Imap相关代码将SSLException转换成了MessagingException的子类。

Exchange代码登陆如下：

public Bundle checkSettings() throws MessagingException {
    try {
        IEmailService svc = getService();        
    if (svc instanceof EmailServiceProxy) {
            ((EmailServiceProxy)svc).setTimeout(90);
        }
        HostAuthCompat hostAuthCom = new HostAuthCompat(mHostAuth);
        return svc.validate(hostAuthCom);
    } catch (RemoteException e) {
        throw new MessagingException("Call to validate generated an exception", e);
    }
}

由于Exchange服务运行在独立的进程，这里将RemoteException转换成了MessagingException。
有了上面的抽象，用户界面的代码就只需要关注MessagingException即可：

@Override
protected MessagingException doInBackground(Void... params) {
    try {
        //do something
        if ((mMode & SetupDataFragment.CHECK_INCOMING) != 0) {
            final Store store = Store.getInstance(mAccount, mContext);
            final Bundle bundle = store.checkSettings();
        }
        //do something
        return null;
    } catch (final MessagingException me) {
        return me;
    }
}

@Override
protected void onPostExecute(MessagingException result) {
    int progressState = STATE_CHECK_ERROR;
    final int exceptionType = result.getExceptionType();

    switch (exceptionType) {
        // handle the exception
    }
}

如果在后续代码中又要增加其他的认证方式，只需要实现新的Store的子类，并抽象可能遇到的异常即可。

• 抛出异常时包含足够的信息
  当程序发生异常时，例如Android开发中很常见的Java Crash，日志信息中一般都会包含出现异常时的调用栈，以及异常信息toString()方法返回的信息。在抛出异常时，应尽可能包含足够多的信息。以IndexOutOfBoundsException为例：

java.lang.IndexOutOfBoundsException: Index: 3, Size: 3

发生异常时打印出了Index值以及数组的长度，出现问题时便于排查。

EmailProvider代码中的findMatch 也是一个很好的例子：

private static int findMatch(Uri uri, String methodName) {
    int match = sURIMatcher.match(uri);
    if (match < 0) {
        throw new IllegalArgumentException("Unknown uri: " + uri);
    } else if (Logging.LOGD) {
        LogUtils.v(TAG, methodName + ": uri=" + uri + ", match is " + match);
    }
    return match;
}

• 原子性的处理异常
  当某个对象抛出异常时，理想情况下这个对象应该仍然处于一个可以稳定的可以使用的状态。尤其对于检查型异常，使用对象的代码通常捕获异常后可以尝试恢复措施。一个简单的办法是，调用一个方法发生异常时，相关的对象应该初一方法调用之前的状态。下面是一个例子：

public Object pop() {
    if (size == 0) {
        throw new IllegalStateException("Stuck is empty");
    }
    Object result = elements[--size];
    elements[size] = null;
    return result;
}

如果没有throw new IllegalStateException("Stuck is empty")，语句当栈为空时，执行到Object result = elements[--size]会抛出IndexOutOfBoundsException，但是此时 size已经变为-1，整个栈 已经无法进行后续的操作（比如POP）。