正确使用RuntimeException？

Question

可能的重复：
在Java中，什么时候应该创建检查异常，什么时候应该创建运行时异常？

什么时候应该从 RuntimeException 而不是 Exception 派生异常？

RuntimeException 不必在方法的 throws 子句中声明，这可能是好，因为它不需要不必特别列出或坏，因为显式声明方法的异常是一种很好的做法。

想法？

Answer 1

来自未经检查的异常——争议：

如果可以合理地预期客户
要从异常中恢复，请使其
一个已检查的异常。如果一个客户
无法采取任何措施来恢复
异常，使其成为未经检查的
异常。

请注意，未经检查的异常是源自 RuntimeException< /a> 和受检查的异常是派生自 Exception。

如果客户端无法执行任何操作来从异常中恢复，为什么要抛出 RuntimeException？文章解释道：

运行时异常代表问题
这是编程的结果
问题，因此，API 客户端
不能合理地期望代码
从中恢复或处理它们
反正。此类问题包括
算术异常，例如
除以零；指针异常，
例如尝试访问一个对象
通过空引用；和索引
例外情况，例如尝试
通过访问数组元素
索引太大或太小。

Answer 2

在企业应用程序开发中，有很多场景会使用 RuntimeException 而不是 Exception。以下是非常常见的两种此类场景：

• 在将异常处理作为一个方面实现（分离关注点设计原则）时，在大多数现代框架中，您将声明性地处理异常并关联特定的异常处理块，而不是对其进行硬编码。一个很好的例子是 Spring 中的 JDBC 模板，它将所有 SQL 异常转换为 RuntimeException，因此开发人员在编写数据访问逻辑时无需编写 try catch 块。您可以以声明方式定义异常处理程序，该处理程序可以在开发环境中提供不同的行为。以及生产中的不同行为。 Struts 1.x Action 类中也有类似的实现，其中执行方法被声明为抛出异常，并且在 struts-config 中映射了单独的 ExceptionHandler 来处理特定的异常。虽然这不是 RuntimeException 的示例，但设计原理是相同的，将正常执行和异常处理的关注点分开。
• RuntimeException 的另一个用途是在 EJB 和其他事务管理器中，其中事务由容器进行控制器。按照惯例，在此类容器中，如果您从代码中抛出 RuntimeException，则事务将回滚 - 如果您抛出异常，则不会发生同样的情况。

我立即想到了这两个重要场景，但当然还有其他场景。