Serviceを読んで理解し、同意したものとみなします。スタック・オーバーフローはプログラマーとプログラミングに熱心な人のためのQ&Aサイトです。合致している、という話を耳にします。説明ないし、ソースを見つけられずにいるのですが、ご存知の方はいらっしゃいますでしょうか。票5SpringのコアはDIコンテナです。DI(依存性の注入)を導入する目的は、利便性など色々ありますが、最大の目的はコンポーネント間の結合度を下げることにあります。対して検査例外は、プロシージャ内部で発生したエラーが、回復可能であることを呼び出し元に通知する仕組みです。呼び出し元コンポーネントが例外をハンドリングするということは、子コンポーネントの実装の詳細を知る必要があるということです。これはDIの概念と真っ向から衝突します。分かりやすい例がSQLExceptionです。Springを使う場合、データベースから業務データをBeanで取得するケースも多いと思いますが、一般的なJavaでデータベースを扱う場合、SQLExceptionのハンドリングは避けられません。SQLExceptionが返却するエラーコードはDB製品固有のものであり、コンポーネントの密結合化に繋がります。そこで、Springでは検査例外のSQLExceptionを、非検査例外のDataAccessExceptionに抽象化することで、コンポーネント内部で例外が閉じるような設計に矯正しています。加えて、SpringではDIコンテナにAOP(アスペクト指向プログラミング)を連携させることで、例外処理を挿入したハンドラインスタンスに行わせることができます。業務例外やシステム例外の処理を、それぞれのロジックに書くのではなく、振る舞いのみを抽出して横断的に処理をする、「関心の分離」というやつです。この辺りの概念に通じてくると、自然と検査例外に対して、コンポーネント間で実装の詳細を共有する必要が生まれ、疎結合化を阻害する検査例外は例外処理のボイラープレートコードを強制し冗長であるという思考が生まれて、「非検査例外を使用する」という方向に寄るんじゃないんでしょうか。Documentationで見つけられます。Releaseにphilosophyとprinciplesについての言及がありました。|回答スタック・オーバーフローに参加してくれて、ありがとうございます!質問の回答を共有してください。回答を説明し、自分の検討結果も共有してください。意見を述べること(意見を述べるなら、参照リソース、自分の経験で意見をサポートしてください)さらにサポートが必要な場合このヘルプを参考してください。“回答を投稿”をクリックすることで利用規約、プライバシーポリシー、及びクッキーポリシーに同意したものとみなされます。タグが付いた他の質問を参照するか、自分で質問をする。Bootでデータベースから値を取ってきて表示する時にNullpointerExceptionが出ます。質問のフィードこのRSSフィードを購読するには、このURLをコピーしてRSSリーダーに貼り付けてください。