System.out.println（）不抛出异常，但System.in.read（）抛出异常，为什么？

Question

我得到这个从的Java™I/O，第二版 通过埃利奥特·鲁斯蒂·阿罗德： -

---

这将是不方便环绕每次调用的System.out.println一个try/catch块（）中，Sun决定让PrintStream（和更高版本的PrintWriter）捕获print（）或println（）方法中引发的异常。如果你想检查异常打印（）内或调用println（）方法，你可以调用checkError（）：

公共布尔checkError（）

的checkError（）方法返回true，如果有异常有发生在此打印流上，如果没有打印，则为false。它只会告诉你发生了一个错误。它不会告诉你发生了什么样的错误。如果您需要更多地了解错误，则必须使用不同的输出流或编写器类。

---

我只是瓦纳测试真正的返回类型此checkError方法....

为这个创造一些实践性的场景，任何线索...... :-)

Answer 1

这里有一对夫妇的场景中checkError()将返回true：

方案1

1. 将文件的输出流打开到小文件系统/设备;例如一张软盘？
2. 创建一个PrintStream
3. 永远写入PrintStream的循环。

最终文件系统将填满，写入将失败。

方案2

1. 打开一个URL连接到一些HTTP服务器。
2. 获取的OutputStream用于连接
3. 创建一个PrintStream
4. 写一些输出到的PrintStream。
5. 在连接上调用getStatus（），或者调用closeConnection
6. 尝试写入更多的输出。

写入现在应该失败，因为HTTP连接不再处于将数据发送到远程服务器的正确状态。

这些场景很实用，从某种意义上说，您应该能够让它们给您带来错误。但它们并不完全现实。例如，您通常不会使用PrintStream将POST数据发送到HTTP服务器。但这是OutputStream与PrintStream API差异的根源。 OutputStream/Writer API专为应用程序需要知道输出是否失败的用例而设计。PrintStream/PrintWriter API专为“轻量级”用例而设计，如将用户消息输出到处理失败的控制台......呃......浪费程序员的工作量。