正确使用RuntimeException？

Question

  

可能重复：
  In Java, when should I create a checked exception, and when should it be a runtime exception?

我应该何时从RuntimeException而不是Exception派生例外？

RuntimeException不必在方法的throws子句中声明，该子句可能 good ，因为它不必特别列出或 坏 ，因为明确声明方法的异常是一种好习惯。

思考？

Answer 1

来自Unchecked Exceptions -- The Controversy：

  

如果可以合理地预期客户   从异常中恢复，成功   检查的例外。如果是客户   无法从中恢复过来   例外，让它不受控制   异常。

请注意，未经检查的异常是从RuntimeException派生的异常，而已检查的异常是从Exception派生的异常。

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

  

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

Answer 2

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

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

这些是我立即想到的两个重要场景，但当然会有其他场景。