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

Question

这有什么好处/垮台吗？

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

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

但是当使用a时Scanner,你不会被迫处理异常.相反,如果抛出一个,你会使用Scanner#ioException().

我知道Scanner不是一个流,而不是一个解析数据的tokenizer,如果需要,但为什么它处理它的异常不像其他涉及IO的行为？我什么时候应该以这种方式处理异常？

Answer 1

解释由类文档给出java.util.Scanner.

扫描程序可以从任何实现Readable接口的对象读取文本.如果对底层可读的Readable.read(java.nio.CharBuffer)方法的调用抛出IOException,则扫描程序会假定已到达输入的结尾.可以通过ioException()方法检索底层可读引发的最新IOException.

它Scanner是较低级别I/O读取器的更高级别的消费者,并处理异常本身.如果您需要/需要该ioException()方法,则该方法可用.在某些构造函数之外,Scanner API的行为是明确定义的,无需调用者捕获任何与I/O相关的异常.

好处是调用者不需要编写try/catch块或使自己的方法抛出checked IOException类型.这是可能的,因为Scanner实现已经以不需要例外作为流控制的方式处理这些边缘情况.

相反,如果扫描程序方法抛出一个已检查的异常,那么catch如果您有合理的方法从异常情况中恢复,那么您作为调用者应该只编写一个块.实际上,您将被迫编写它,或者,如果您没有捕获它,现在您的类 API变得"污染",通过声明其方法仅仅因为实现细节而抛出已检查的异常(因为您碰巧使用了扫描程序)类).

另一方面,低级Readable接口及其实现无法处理异常情况,并被迫将它们抛给调用者; 他们无法知道"正确"的恢复手段是什么,或者是否存在任何合适的手段.抛出已检查的异常可能是必要的,但优秀的API会尽可能避免使用它.