2

我们正在评估 JDO 在我们的应用程序中用作数据管理层。要求是具有与任何数据存储的零依赖关系的抽象良好的数据管理。

我们发现 JDO 非常有前途，并且正在了解数据核的实现。

我们考虑的一件突出的事情是 JDO 主要遵循运行时异常策略。

见 http://docs.tpu.ru/docs/oracle/en/fmw/11.1.1.6.0/apirefs.1111/e13946/jdo_overview_arch.html

所有 JDO 异常的父异常是 javax.jdo.JDOException 并且正在扩展运行时异常。

我们知道调用 API 时引发的异常显然是运行时的。但是，如果我们有一个已检查的异常，它是否易于管理？

请对此发表评论。有人可以帮助理解通过 API 使用运行时异常的理念吗？

4

1 回答 1

1

了解使 api 引发 Runtime 异常的使用方法。请点击此链接。很好 http://onjava.com/onjava/2003/11/19/exceptions.html

上面链接中的一句话说

永远不要让特定于实现的检查异常升级到更高层。例如，不要将 SQLException 从数据访问代码传播到业务对象层。业务对象层不需要知道 SQLException。你有两个选择：

如果期望客户端代码从异常中恢复，则将 SQLException 转换为另一个检查异常。

如果客户端代码对此无能为力，则将 SQLException 转换为未经检查的异常。

大多数时候，客户端代码对 SQLExceptions 无能为力。不要犹豫，将它们转换为未经检查的异常。

我认为这清楚地解释了运行时异常的好处

于 2012-12-04T11:35:47.967 回答