System.out.println（）不會引發異常，但是System.in.read（）會引發異常，為什么？

Question

我是從Java™I / O（第二版）獲得的，這是Elliotte Rusty Harold撰寫的：

---

將try / catch塊包裝在對System.out.println（）的每次調用周圍會很不方便，Sun決定讓PrintStream（以及后來的PrintWriter）捕獲並吃掉print（）或println（）方法中引發的任何異常。 如果您確實想在print（）或println（）方法中檢查異常，則可以調用checkError（）：

公共布爾checkError（）

如果此打印流上發生異常，則checkError（）方法返回TRue，否則返回false。 它僅告訴您發生了錯誤。 它不會告訴您發生了哪種錯誤。 如果您需要更多有關該錯誤的信息，則必須使用其他輸出流或writer類。

---

我只是想測試此checkError方法的真實返回類型。

有關為此創建一些實際方案的任何線索... :-)

Answer 1

這有兩個場景，其中checkError()將返回true ：

場景1

1. 打開文件輸出流到小型文件系統/設備； 例如軟盤？
2. 創建一個PrintStream
3. 循環以寫入PrintStream。

最終，文件系統將填滿，並且寫入將失敗。

場景2

1. 打開到某些HTTP服務器的URL連接。
2. 獲取連接的OutputStream
3. 創建一個PrintStream
4. 將一些輸出寫入PrintStream。
5. 在連接上調用getStatus（），或調用closeConnection
6. 嘗試編寫更多輸出。

現在寫入將失敗，因為HTTP連接不再處於將數據發送到遠程服務器的正確狀態。

從您應該能夠使它們給您帶來錯誤的意義上說，這些方案是實用的。 但是它們並不完全現實。 例如，您通常不會使用PrintStream將POST數據發送到HTTP服務器。 但這是OutputStream API和PrintStream API之間差異的根源。 OutputStream / Writer API專為應用程序需要知道輸出是否失敗的用例而設計。 PrintStream / PrintWriter API專為“輕量級”用例而設計，例如將用戶消息輸出到處理失敗的控制台，這很浪費程序員的精力。