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專爲「輕量級」用例而設計，如將用戶消息輸出到處理失敗的控制檯......呃......浪費程序員的工作量。