このサービスでドキュメントを検証するときのチェック済み例外とチェックなし例外
ユーザーが動的コンテンツをリポジトリに追加できるサービスがあります。したがって、基本的には、ユーザーが追加しているドキュメントのタイプに応じて、その特定のオブジェクトのプロパティのリストを含む汎用のDocumentクラスがあります（たとえば、請求書ドキュメントには請求書番号プロパティがあり、Wikiドキュメントには作成者プロパティがあります）。オン）。
サービスはさまざまなレイヤーで構成されており、ある時点で、追加するドキュメントがルール構成に準拠しているかどうかを確認し、必要なすべてのプロパティが提供されているかどうか、すべてが適切なタイプであるかどうかを評価する必要があるクラスなどがあります。これらの検証のいずれかが失敗した場合、検証ステータスを含むカスタム例外をスローしたいと思います。
質問は：
- ValidationExceptionをオンにするかオフにするか
どのような例外の使用を決定するかについて、多くのベストプラクティスを読みました。私はRuntimeExceptionの使用を考えていましたが、この場合、例外はコーディングのエラーやそのようなものではなく、ユーザー入力によって引き起こされています...
一方、チェックされた例外を使用すると、アプリケーションの上記のすべてのレイヤー、およびおそらくサービスのメソッドの90％で「スロー」構文が伝播され、コードの可読性と保守性が大幅に低下します。
オラクルのドキュメントはそれについてもっと明確にすることはできないと思います：
一般的に、メソッドがスローできる例外の指定に煩わされたくないという理由だけで、RuntimeExceptionをスローしたり、RuntimeExceptionのサブクラスを作成したりしないでください。
要点のガイドラインは次のとおりです。クライアントが例外からの回復が合理的に期待できる場合は、チェックされた例外にします。 クライアントが例外から回復するために何もできない場合は、チェックされていない例外にします。
これが事実であるかどうかを知っているのはあなただけです。
本当の問題は、チェックされた例外かチェックされていない例外かではなく、適切に処理されるためにチェックされた例外を（あなたが言ったように）伝達しなければならない多くのレベルだと私は思います。おそらく、あなたのデザインについてもう少し詳しく教えてください。
チェックされた例外を使用して、コンパイラが常にそれをキャッチするように通知する必要があります。
検証が失敗した場合は、とにかくそのエラーをキャッチしたいので、なぜ未チェックの例外を使用し、この例外がスローされる可能性があることをおそらく忘れてください。
この特定のケースの詳細については、次も読むことができます。 http://learnjava.today/2015/11/checked-vs-unchecked-exceptions/