java - 为什么 Scanner 使用 Scanner#ioException() 而不是抛出异常？

Question

这样做有什么好处/坏处吗？

通常，从流中读取时会抛出异常:

try {
    inputStream.read();
}catch(IOException e) {
    e.printStackTrace();
}

但是当使用Scanner 时，您不会被迫处理异常。相反，如果抛出一个，您将使用 Scanner#ioException()。

我知道 Scanner 不是一个流，而是一个在需要时解析数据的分词器，但为什么它处理它的异常不同于涉及 IO 的其他操作？我什么时候应该以这种方式处理异常？

Answer 1

解释由 class documentation for java.util.Scanner 给出.

A scanner can read text from any object which implements the Readable interface. If an invocation of the underlying readable's Readable.read(java.nio.CharBuffer) method throws an IOException then the scanner assumes that the end of the input has been reached. The most recent IOException thrown by the underlying readable can be retrieved via the ioException() method.

Scanner 是较低级别 I/O 读取器的较高级别消费者，并自行处理异常。 ioException() method 如果您想要/需要它，使该异常可用。在某些构造函数之外，Scanner API 的行为定义明确，不需要调用者捕获任何与 I/O 相关的异常。

好处是调用者不需要编写 try/catch block 或让他们自己的方法抛出 checked IOException 类型。这是可能的，因为 Scanner 实现已经以不需要 exceptions as flow control 的方式处理这些边缘情况。 .

如果相反，Scanner 方法要抛出一个已检查的异常，那么作为调用者，如果您有从异常情况中恢复的合理方法，您应该只编写一个 catch block 。实际上，您将被迫编写它，或者，如果您没有捕捉到它，现在您的类 API 通过声明其抛出已检查异常的方法而变得“被污染”仅仅因为一个实现细节(因为您碰巧使用 Scanner 类)。

另一方面，较低级别的 Readable 接口(interface)及其实现无法处理异常情况，并且被迫将它们抛给调用者；他们无法知道什么是"正确"的恢复方式，或者是否存在任何合适的方式。抛出已检查的异常可能是必要的，但好的 API 会尽可能避免它。