アプリケーションでデータ管理レイヤーとして使用するためにJDOを評価しています。要件は、どのデータストアとも依存関係がない、十分に抽象化されたデータ管理を行うことです。
JDOは非常に有望であり、DataNuclearの実装を理解しています。
私たちが考慮した重要な点の1つは、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全体でランタイム例外を使用するという哲学を理解するのに役立つ人はいますか？
APIがランタイム例外をスローする方法を理解する。このリンクをたどってください。いいですね http://onjava.com/onjava/2003/11/19/exceptions.html
上記のリンクからの1つの引用は言う
実装固有のチェック済み例外を上位層にエスカレートさせないでください。たとえば、SQLExceptionをデータアクセスコードからビジネスオブジェクトレイヤーに伝播しないでください。ビジネスオブジェクトレイヤーは、SQLExceptionについて知る必要はありません。2つのオプションがあります。
クライアントコードが例外から回復すると予想される場合は、SQLExceptionを別のチェック済み例外に変換します。
クライアントコードがSQLExceptionについて何もできない場合は、SQLExceptionをチェックされていない例外に変換します。
ほとんどの場合、クライアントコードはSQLExceptionsについて何もできません。それらをチェックされていない例外に変換することを躊躇しないでください。
これは、ランタイム例外の利点を明確に説明していると思います