私の理解では、チェックされた例外は、の呼び出し元が回復することが合理的に期待できる例外です。これがInstantiationExceptionの場合である理由がわかりません。クラスをインスタンス化できない場合、呼び出し元は何をする必要がありますか？
次に、コードがコンパイルされたことは重要な考慮事項であると思いました。したがって、これは、クラスが動的に指定されている場合にのみ発生する可能性があります。1 この場合、クラスはパラメーターに似ている可能性がありますが、実行時例外であるIllegalArgumentExceptionがあります。
標準の例外がチェックされ、チェックされない理由は何ですか？
1これは本当ですか？
私が考えることができるこの例外を明示的に処理する理由の1つ（しかし、それは信頼できる答えではありません）：
リフレクションを使用してクラスをインスタンス化してみてください（そのクラスは静的にリンクされているのではなく、構成されているため）。期待されるコンストラクター署名がない場合は、別のコンストラクターを試してください。または別のクラス。フレームワークコード（Springなど）には、そのようなロジックが含まれている可能性があります。
InstantiationExceptionのJavaDocから：
アプリケーションがクラスClassのnewInstanceメソッドを使用してクラスのインスタンスを作成しようとしたが、指定されたクラスオブジェクトはインターフェイスであるか抽象クラスであるため、インスタンス化できない場合にスローされます。
これは、Javaリフレクションを使用する場合、たとえば、いわばClassName.class.newInstance()対照的に、プログラムでオブジェクトをインスタンス化する場合にのみ発生します。new ClassName()リフレクションを使用して、抽象クラスやインターフェイスのインスタンス化などの異常を処理するコードを記述したり、コンストラクターの呼び出し中に例外がスローされた場合（この場合はを使用できますe.getCause()）を期待するのは自然なことです。
コードで処理されることは期待されていませんが、リフレクションを使用する特定のAPI/ライブラリによって処理されることが期待されています。
Class.newInstance（）には、InstanciationExceptionがいつスローされるかについての興味深い説明があります[javadoc]：
InstantiationException-このクラスが抽象クラス、インターフェイス、配列クラス、プリミティブ型、またはvoidを表す場合。または、クラスにnullaryコンストラクターがない場合。または、他の理由でインスタンス化が失敗した場合。
私には、静的にリンクされたクラスのインスタンス化がコンパイル時に失敗するすべてのケースをカバーしようとしているように見えます。
最も重要な部分は、私が強調した部分です。チェックされた例外をスローするコンストラクターを想像してみてください。そのコンストラクターが動的に呼び出された場合はどうなりますか？誰がその貧弱なチェック例外をチェックしますか？
InstantiationException javadocのjavadocからわかるように、スローされます
アプリケーションがクラスClassのnewInstanceメソッドを使用してクラスのインスタンスを作成しようとしたが、指定されたクラスオブジェクトをインスタンス化できない場合。
あなたはそのようなコードを完全に書くことができます：
try {
Class myClass = Class.forName("Myclass");
myClass.newInstance();
} catch (ClassNotFoundException e) {
} catch (InstantiationException e) {
} catch (IllegalAccessException e) {
}
いいえIllegalArgumentExceptionがスローされます。
回復が容易かどうかではなく、例外の原因についてcheckedです。vsuncheckedについてもっと読むchecked
チェックされた例外とチェックされていない例外の間には広大な灰色の領域があり、多くの例外はほぼ間違いなく何らかの方法で設計できますが、これはそうではありません。これは間違いです。チェックを外しておく必要があります。