Java Data Objects Specification using only Runtime Exceptions?

Question

We are evaluating JDO for using as the Data Management Layer in our application . The requirement is to have a well abstracted Data management with zero dependencies with any of the Data stores.

We found JDO very promising and is understanding the Data nucleus implementation.

One prominent thing came into our consideration is that JDO is predominantly following a runtime exception strategy.

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

The parent exception to all JDO exceptions are javax.jdo.JDOException and is extending the Runtime Exception.

We understand that exceptions that are raised while calling the API are obviously runtime. But if we had a checked exception had it been easy to manage ?

Please comment on this . Can some one help in understanding the philosophy of using Runtime exceptions through out the API .

Answer 1

To understand the use of making the api throw Runtime exception. Please follow this link. It is nice http://onjava.com/onjava/2003/11/19/exceptions.html

One quote from above link says

Never let implementation-specific checked exceptions escalate to the higher layers. For example, do not propagate SQLException from data access code to the business objects layer. Business objects layer do not need to know about SQLException. You have two options:

Convert SQLException into another checked exception, if the client code is expected to recuperate from the exception.

Convert SQLException into an unchecked exception, if the client code cannot do anything about it.

Most of the time, client code cannot do anything about SQLExceptions. Do not hesitate to convert them into unchecked exceptions.

I think this clearly explains the benefit of runtime exceptions