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