问题描述
|
最近有人问我一个有关扩展java.lang.RuntimeException的问题，显然是在采访中。
我被要求举一个需要扩展java.lang.RuntimeException的示例。
我一直以为我们不需要扩展RuntimeException，有人可以启发我吗？
谢谢，
SB
解决方法
一层的运行时异常是另一层的已检查（并已执行）异常。
我可以看到容器servlet容器； REPL和/或任何顶级解释器循环；等合法选择和捕获RuntimeException，因为它们不应仅仅因为某些东西在堆栈中更深入而崩溃。
与容器的情况类似，跨越邻接边界例如跨层或跨层通常要求更加明确的异常语义。
如果“原因”和/或消息属性在语义上证明不足以表示“嘿，它坏了”以外的任何内容，并且客户端/高层可以选择性地执行操作，则可以合理地将RuntimeException子类化。
, 在创建不必显式捕获的异常（未经检查的异常）时，您想扩展RuntimeException。这是例外情况，表示通常无法恢复的问题（例如，死数据库）。
您应该看一下Java中检查和未检查异常之间的区别。
,
RuntimeException是的超类
那些可以抛出的异常
在正常运行期间
Java虚拟机。
不需要在中声明的方法
它的throws子句的任何子类
可能引发的RuntimeException
在执行方法期间
没有抓住。
请参阅RuntimeException
, RuntimeException是在Java虚拟机的正常操作期间可能引发的那些异常的超类。
如果将新功能添加到jdk或修改jvm实现，则应扩展RuntimeException以便添加新的RuntimeException。
, 您应该坚持不应该扩展此异常，因为该异常通常应在无法执行更多操作且应中断操作的地方使用。
但是，如果您需要针对这种情况找到一个应用程序，则可以说通过创建不同类型的RuntimeException，我们可以在out异常处理程序中拥有更多控制权，以显示异常信息等。但是恕我直言，这只是一场演讲。
, 当客户端无法从程序中合理恢复时，我将抛出运行时异常，
这些通常是未经检查的异常，主要是代码中的错误，在该错误中客户端不希望在运行时恢复
示例：到数据源的死链接，JNDI绑定失败，某些操作（分母为零的除法）的前提条件失败是此RuntimeException子类的方案