Java PrintWriter和PrintStream从不抛出IOException

几天前，我意识到（以及）在编写、刷新或关闭时从不抛出IOException

相反，当发生错误时，它会设置一个内部标志（

trouble=true

） 不可能得到确切的异常，但只有在出现异常（）时才能得到

---

我的问题是：一个人为什么要有这样的行为？这不是很糟糕的API设计吗？

我不太了解这个故事，但我认为这是为了让新的程序员更容易使用Java，他们希望能够使用简单的stdio打印方法，而不需要知道什么是异常。因此，在这方面，这是一个很好的设计（尽管我有点同意你的观点）。

设计可能是由来自C背景的人完成的，在C背景下，stdio错误的处理方式与此类似。既然我已经习惯了这种模式，我不会说它不好，但我同意它是不一致的

---

我也同意关于努力使PrintWriter更易于使用的评论。Java中的IO类令人困惑（至少对我认识的每个人来说），也许有人只是想让生活变得简单一点。

我认为，由于

System.out

和

System.err

是

PrintStream

的实例，因此提供了一些更轻松的错误处理。正如其他海报所提到的，这可能是为了为大约1995年从C/C++过渡的人铺平道路。添加读写器API时，会创建

PrintWriter

，以与现有的

PrintStream

并行

---

这种行为非常可取的一个应用程序是日志记录。日志记录是大型应用程序的辅助功能。通常，如果日志记录失败，人们不希望整个应用程序失败。因此，

System.err

，至少忽略异常是有意义的。

我想知道是否因为检查了IOExceptions，所以需要在每个System.out周围放置一个try-catch块。打电话

更新：或者抛出方法签名

---

这会很快让人恼火。

这不是设计错误。这是一种合适的设计，用于编写输出并希望忽略错误的情况

作为一个典型的用例，

System.out

和

System.err

已经被提到，但原因不是为了方便或平滑的C/C++转换而放松处理。这是对这种情况的理想处理：

• 您可以在控制台中启动应用程序
• 它产生到标准输出/错误的输出
• 您关闭控制台，但希望应用程序在后台继续

在这种情况下，根据系统实现，控制台关闭后，

system.out

或

system.err

可能会失败，但您不希望这会使应用程序崩溃。该应用程序希望继续在后台运行，输出将被删除。这就是

PrintWriter

所做的

如果您关心输出过程中的错误，请使用

FileWriter

或

OutputStreamWriter

。

---

如果您需要

PrintWriter

中可用而

FileWriter

中不可用的某些方法，请创建自己的TextWriter扩展

FileWriter

或

OutputStreamWriter
，当然，选中的异常并不严格要求try-catch块。PrintStream很少在生产代码中使用，它在核心库中的使用仅限于日志记录，在日志记录中可以安全地忽略故障。它们仍然可以引发运行时异常，而不是IOException，而不是设置内部标志。我只是在查找。我也觉得很奇怪。隐藏异常是一回事，但完全放弃它？如果我真的想知道异常的内容呢？我需要一个getError（）方法，但。。。这是一个非常奇怪的设计决定。