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来“弹出”不重要的信息，而使用对话框显示重要的信息并得到确认。
