我知道如果我们希望调用方法处理它，我们可以为我们的方法声明异常。如果封闭方法抛出 IOException，这甚至允许我们执行诸如写入 OutputStream 之类的操作，而无需将代码包装在 try/catch 块中。
我的问题是：谁能提供一个通常在您希望调用方法而不是当前方法处理异常的情况下执行此操作的实例？
编辑：我的意思是在最后一行调用方法而不是超类。
【问题讨论】：
标签： java exception exception-handling try-catch throws
是的，我会声明它，以便它向上传播，直到实际处理它的父调用方法（在 UI 上显示，在那里中断，..）
例如，我可能在 sendEmail 方法中有一些辅助方法。如果辅助方法说 checkEmailAddress() 产生了异常，我希望 sendEmail 知道它，这可以进一步传播它或在 UI 上发出警报“电子邮件错误”
【讨论】：
我使用期望作为在应用程序的架构层之间传输信息的一部分。
例如：
如果 DAO（数据库访问层）收到 SQLException，它会抛出一个自定义的 DAOLayerException，该异常被业务层捕获，而业务层又抛出一个由表示层捕获的异常。
这是针对未经检查的异常。
如果函数要被众多调用者使用或在函数开发时未知，我通常会遵循抛出 checked 未检查异常（不处理它们）的做法。
【讨论】：
你问的是一个例子，这里是一个常见的例子。
如果您正在编写读取特定文件格式的代码，这些通常会声明 IOException。这样做的原因是它可能被桌面应用程序（想要放置一个对话框）或文本实用程序（想要编写错误消息）或网络应用程序（想要返回错误代码）使用.异常处理允许您这样做。
【讨论】：
一般来说，我会说设计您的异常流程，以便异常被可以实际采取适当行动的代码捕获。
这通常意味着在“库”方法（或大型项目中的某种通用实用程序方法）中，您将抛出异常而不捕获它们。
另一方面，如果您发现自己声明您的方法抛出异常，您认为在实践中几乎不会发生（例如，序列化通常涉及各种虚假的检查异常，而实际上这些异常不会发生）发生，例如，如果您要反序列化一个 Integer，则 Integer 类确实不太可能不存在，但您仍然必须捕获适当的异常），那么您有第三种选择重新转换为 RuntimeException。
【讨论】：
如果您希望在应用程序的不同级别处理错误。
这是一个半具体的例子。假设我有一个 Web 应用程序，它被实现为一系列 states 和 actions。假设在处理状态时，数据库访问导致SQLException 被抛出。在我的应用程序正常运行期间不会发生这种情况；只有当数据库出现问题时才会发生这种情况。
访问数据库的方法不需要知道我处理这种半致命错误的过程是什么。该逻辑在更高级别实现 - 在处理状态的方法中 - 对于任何运行时错误基本上都是相同的，无论它是否真的是 RuntimeException：向用户吐出一条漂亮的错误消息告诉他们联系技术支持。
想象一下，如果我必须将执行此逻辑的 try/catch 块添加到 每个 访问数据库的方法中，并且可能会抛出 SQLException。这就是所谓的nightmare。
【讨论】：
如果您不能以合理的方式处理该点的错误（例如显示错误消息、采用替代路径等），那就让它冒泡吧。
【讨论】：
我猜你所说的“超类”是指调用你的方法的代码。
如果您希望调用者比您的方法更了解问题，那么您可以将此责任传递给调用堆栈。
一般来说，如果您不知道如何处理问题，请不要这样做。以太传递它或将其包装在另一个异常中。
【讨论】：
在 web 框架（如 spring）中，您经常让错误传播，容器将处理它们（通过向用户显示错误页面或消息、回滚事务等）。
此外，还有很多您从未发现的 java 错误，例如 OutOfMemoryError。你可以抓住它们，但你不能妥善处理它们。
【讨论】：