これは実際にはコーディングの問題ではないため、SO には適していない可能性がありますが、まだ満足のいく答えを見つけることができず、SO コミュニティならできると思います。
したがって、定義により、android.database.SQLExceptionとjava.sql.SQLExceptionは、データベースへのアクセス/変更中にエラーに関する情報を提供するという、ほぼ同じ適用範囲を共有します。チェックされた例外が「アウト」であることをどこかで読んだことがありますが、throwsキーワードでチェックされた例外を使用すると、コンパイラが例外の処理を思い出させるという事実が本当に気に入っています。残念ながら、これは未チェックの例外では機能しません。
私の質問は: なぜ Googleはチェックされているのにandroid.database.SQLExceptionチェックを外したのjava.sql.SQLExceptionですか? 何か不足していますか？私が思っている以上に違いますか？
例外をチェックするかチェックしないかの選択は、常に多少主観的です。
例外がバグ、または「おそらく回復できない」障害を示している場合は、未チェックの例外が適切です。
例外が「おそらく回復可能」な障害を示している場合は、チェック済み例外が適切です。
多くのサブクラスを持つ一般的な例外があるこのような場合は、より困難です。これらのサブクラスの一部はバグであるか、回復可能である可能性があります。この時点で、設計者は、さまざまなケースの相対的な可能性について価値判断を下す必要があります...例外の既知/予測されたすべてのサブタイプにわたって。
この場合、Sun と Google のエンジニアは異なる結論に達しました。ただし、Google のエンジニアには、Sun のエンジニアにはない大きな利点があったことに注意してください。彼らはJavaの設計を見て、それがチェックされSQLExceptionた.
チェックされた例外が「アウト」であることをどこかで読んだことがありますが...
すべての Java 例外がチェックされないようにして、強制的に処理する必要がないようにしたいと考える開発者はたくさんいます。他の多くの開発者は、Java がチェック済みの例外でそれを正しく行ったと今でも考えています。
それは議論の余地があります。
何か不足していますか？私が思っている以上に違いますか？
あまり。2 つの例外階層は、ほとんど同じ目的を果たします... javadoc クラスの説明の違いにもかかわらず。
android.database.SQLExceptionに基づいてjava.lang.RuntimeExceptionおり、チェックする必要はありませんが、そうでjava.sql.SQLExceptionはありません。
Unchecked Exceptions — The Controversyに、これに関する簡単な説明があります。
多くの場合、チェックされていない例外はチェックされた例外よりも優先されると思います。その理由は、あなたがそれを捕まえることを決して強制されないからです。try-catch必要だと思う場合は、コードを句で囲むことができますが、そうする必要はありません。これにより、プログラマーが何をすべきかを決定できるため、コードが効果的に改善されます。
あなたの例では、それを作らなければならない特別な理由はありcheckedません。それはデザインの問題であり、それによってグーグルはより良い仕事をしたと思いますandroid.database.SQLException。
私がそう思う理由は：
android.database.SQLException：SQLの解析または実行でエラーが発生したことを示す例外。
と
java.sql.SQLException：データベースアクセスエラーまたはその他のエラーに関する情報を提供する例外。
したがって、 SQLの解析または実行でエラーが発生した場合に発生するandroid.database.SQLException可能性が高いことは明らかです。RuntimeException一方、java.sql.SQLExceptionはデータベースアクセスエラーなどのエラーによる例外であるため、チェック例外として保持するのに十分な有効性があります。開いている接続、またはそのような種類のもので作業するときはいつでも、チェックされた例外の傘下にそれらを置くことをお勧めします。