2.2 异常处理
Ian Darwin
2.2.1 问题
Java有一个精心定义的异常处理机制,但是需要花费一定的时间学习,才能高效地使用而不至于使用户或者技术支持人员感到沮丧。
2.2.2 解决方案
Java提供了一个Exception层次结构,正确地使用它能够带来相当大的灵活性。Android提供了包括对话框和Toast的多种机制,用于通知用户错误的情况。Android开发者应该熟悉这些机制,并学习高效使用它们的方法。
2.2.3 讨论
Java从推出时就有两类异常(实际上是Exception类的父类Throwable):检测型(checked)异常和非检测型(unchecked)异常。在Java标准版中,编程人员明显要面对这样一个事实:在编译的时候可以检测到某些情况,但其他的情况则无法检测。例如,如果许多PC上安装一个桌面应用程序,可能有些PC上的磁盘空间已经很紧张,无法保存数据;与此同时,其他PC上应用程序依赖的一些文件可能由于用户的错误(而非编程人员的错误)、偶发事件、老鼠咬断电缆等情况而丢失。因此,IOException被当作“检查型异常”,意味着编程人员必须检查这类异常,检查可以通过文件使用方法中的try-catch子句或者方法定义中的throws子句来完成。所有经过良好训练的Java开发人员都知道如下的通用规则:
Throwble是可抛出异常层次结构的根。Exception及其子类(RuntimeException(及其子类)除外)都是检测型异常。其他异常为非检测型异常。
上述规则意味着,Error及其所有子类都是非检测异常(见图2-1)。例如,如果你收到一个VMError异常,说明出现了一个运行时bug,作为应用程序编程人员,对此你没有什么可做的。RuntimeException子类包含了名称超长的ArrayIndexOutOfBoundsException等异常,它和它的友元都是非检测型异常,因为在开发时测试及捕捉这些异常是你的责任(参见第3章)。
捕捉异常的场所
早期对检测型异常的(过度)使用导致许多早期Java开发人员编写的代码中到处都是try/catch代码块,部分原因是:在早期的一些培训项目和书籍中,对throws子句的使用没有得到足够的重视。随着Java本身越来越多地转向企业应用,较新的框架(如Hibernate和Spring)出现并强调非检测型异常的使用,这类问题才得到改正。现在,尽可能捕捉靠近用户的异常这一理念已经得到普遍的接受。准备(在程序库或者多个应用程序中)重用的代码不应该尝试错误处理,它们所能做的是所谓“异常转译”(Exception Translation),也就是说,将与技术相关的(通常是检查型)异常转换为通用的非检测型异常。例2-1展示了基本的模式。
例2-1:异常转译
public String readTheFile(String f) {
BufferedReader is = null;
try {
is = new BufferedReader(new FileReader(f));
String line = is.readLine();
return line;
} catch (FileNotFoundException fnf) {
throw new RuntimeException("Could not open file " + f, fnf);
} catch (IOException ex) {
throw new RuntimeException("Could not read file " + f, ex);
} finally {
if (is != null) {
try {
is.close();
} catch(IOException grr) {
throw new RuntimeException("Error on close of " + f, grr);
}
}
}
}
注意,即便在这个代码中,检测型异常的用法也很零乱:is.close()实际上不可能失败,但是因为将它放在finally块中(如果文件打开但是出现了某种错误,这样可以确保文件关闭),就必须使用另一个try-catch结构。因此,检测型异常(很可能)是不好的,在新的API中应该避免使用它,在必要时应该用非检测型异常来扫清道路。
Oracle官方网站和其他人则支持相反的看法。在本书网站上的一条评论中,Al Sutton提出了如下看法:
检测型异常迫使开发人员承认错误的情况可能发生,他们必须思考处理错误的方式。在许多情况下,除了日志和恢复可能没有太多的事情可做,但是开发人员仍然考虑到此类错误发生的时候所应采取的措施。这个例子说明阻止方法调用者区分文件不存在(因而没有必要重新读取)和文件读取问题(文件存在但是无法读取)这两种不同错误情况之间的区别。
Android忠于JavaAPI,有许多检测型异常(包括例子中说明的那些),因此对这些异常应该以相同的方式处理。
对异常的处理
应用程序应该始终报告异常。当我看到捕捉的异常却不采取任何措施的代码时,我总会感到绝望。但是,异常只应该报告一次(不要既进行记录,又转译/重新抛出异常)。普通异常的重点是表示异常情况(正如名称所表示的那样)。因为在Android设备上没有系统管理员或者控制台操作员,所以必须向用户报告异常情况。
你应该考虑通过一个对话框或者Toast通知报告异常。移动设备上的异常处理与台式机有所不同。用户可能正在开车(或者操作其他机器),与人交谈,因此你不应该猜测他们的注意力都在应用程序上。记住,Toast通知只在屏幕上出现几秒钟,你可能会错过它。如果用户必须采取行动更正错误,就应该使用对话框。我知道大部分的示例(甚至在本书中也是一样)使用Toast,这是因为Toast通知需要的代码比对话框少(相反,BlackBerry API简化了对话框:Dialog.alert("mes sage"))。Toast简单地弹出,然后消失。对话框则要求用户确认异常情况,或者授权应用程序执行某些付费操作(例如,启动互联网访问,以便运行需要下载地图数据的应用程序)。
注意: 使用Toast来“弹出”不重要的信息,而使用对话框显示重要的信息并得到确认。