2.1异常处理


问题
Java有一个定义良好的异常处理机制，但它需要一些时间来学习有效地使用它，而不会使用户或技术支持人。
解
Java提供了一个Exception层次结构，在正确使用时提供了相当大的灵活性。 Android提供了几种机制，包括对话框和面包，用于通知用户错误情况。 Android开发人员应该熟悉这些机制，并学会有效地使用它们。
讨论
Java有两类异常（实际上是Exception的父类Throwable）
因为引入了Java：checked和unchecked。在Java标准版中，显然的意图是强迫程序员面对这样一个事实，虽然某些事情可以在编译时检测到，但其他的不能。例如，如果您在大量PC上安装桌面应用程序，则很可能某些PC上的磁盘容量接近，并且尝试在其上保存数据可能会失败;同时，在其他电脑上的应用程序依赖的一些文件会失去，不是由于程序员错误，而是由于用户错误，文件系统的事情，沙鼠咀嚼电缆，或任何。因此，IOException的类别被创建为“已检查的异常”，这意味着程序员必须通过在file-using方法中使用try-catch子句或在方法定义中使用throws子句来检查它。所有训练有素的Java开发人员记住的一般规则如下：
Throwable是可抛弃层次结构的根。检查异常，并检查除RuntimeException或其任何子类之外的所有其子类。所有其他都是未选中。
这意味着Error和它的所有子类都被取消选中（见图2-1）。如果你得到一个VMError，例如，这意味着在运行时有一个错误。没有什么你可以做这个作为一个应用程序员。和RuntimeException子类包括类似过长的ArrayIndexOutOfBoundsException;
这和朋友不受检查，因为它是你的责任，抓住他们在开发时，通过测试他们。


图2-1。 Throwable层次结构
在哪里捕获异常
（过）使用检查异常导致许多早期的Java开发人员编写代码，其中嵌入了try / catch块，部分是因为在一些训练计划和书籍中没有强调使用throws子句。由于Java本身已经转移到企业工作，而新的框架，如Spring，Hibernate和JPA已经出现，并强调使用未经检查的异常，这个早期的位置已经改变。现在普遍接受的是，你想捕获异常尽可能接近用户。用于重用库或甚至在多个应用程序中的代码不应尝试执行错误处理。它可以做什么是所谓的异常翻译，即将技术特定（通常检查）异常转换为通用的未检查异常。例2-1显示了基本模式。
实施例2-1。异常翻译 

public class ExceptionTranslation {
public String readTheFile（String f）{
try (BufferedReader 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("Problem reading file " + f, ex);
}
}
}



注意，在Java 7之前，你必须编写一个显式的finally子句来关闭文件：

} 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希望忠实于Java API，有许多这些检查异常（包括示例中所示的异常），因此应该以相同的方式对待它们。
如何处理异常
几乎总是报告异常。当我看到代码捕获异常，并没有做任何对他们，我绝望。然而，他们应该只报告一次（不要记录和翻译/重新投掷！）。所有正常例外的意思是指出，顾名思义，一个例外条件。由于在Android设备上没有系统管理员或控制台操作员，因此需要向用户报告异常条件。
您应该考虑是否通过对话框或烤面包报告异常。移动设备上的异常处理情况与台式计算机上的异常处理情况不同。用户可能正在驾驶汽车或操作其他机械，与人交互等，所以你不应该假设你有她的全部注意。请记住，烤面包只会在屏幕上显示几秒钟;闪烁，你可能会错过它。如果用户需要做一些事情来纠正问题，你应该使用一个对话框。我知道大多数例子，即使在这本书中，使用烤面包，因为它涉及较少的编码比对话。
吐司只是弹出然后遗忘。对话框要求用户确认一个特殊情况，并且或者给应用程序许可，可能会花费一些东西（例如打开互联网访问以运行需要下载地图图块的应用程序）。