私は次のことを研究しました。ただし、チェックされていない例外を除いて、コンパイラーはクライアント・プログラマーに例外をキャッチするか、throws節で宣言するように強制しません。実際、クライアントプログラマーは、例外がスローされる可能性があることさえ知らない場合があります。たとえば、StringIndexOutOfBoundsExceptionStringのcharAt()メソッドによってスローされます。
それはどういう意味ですか？
そのコードによると、コードにtry catchブロックを入れる必要はありませんが、コンパイラーがコードをtrycatchブロックに入れるように強制するのを見てきました。
私は彼らが正確に何であるか非常に混乱していますか？
非チェック例外は、RuntimeExceptionクラスを拡張するものです。コンパイラは、そのような例外をキャッチすることを強制したり、throwsキーワードを使用してメソッドで宣言することを強制したりしません。他のすべての例外タイプ (拡張されないRuntimeException) がチェックされるため、スローまたはキャッチされるように宣言する必要があります。
チェック例外は、メソッドの呼び出し元 (つまり、API のユーザー) が API で例外的なケースを明示的に処理するようにする場合に使用されます。チェック例外は、呼び出しの再試行、変更のロールバック、またはユーザーが読み取り可能なエラー メッセージへの変換など、呼び出しがその例外的なケースで意味のあることを実行できると思われる場合に宣言されます。
呼び出しが例外に対してできることは何もないと思われる場合 (特に、バグや API の間違った使用法を表す場合)、例外をチェック解除する必要があります。また、チェックされた例外が多すぎる API を使用すると、プログラミングが面倒になる可能性があります (たとえば、Java リフレクション API= を使用してみてください)。
あなたの質問は正確には何ですか？コンパイラーは、チェックされていない例外を試行/キャッチするように強制するべきではありません（そして強制しません）。
一般的な考え方は、チェックされた例外は予測できるかもしれませんが、制御不能で対処しなければならない入力に基づいている可能性があるということです。チェックされていない例外は通常、プログラムのバグを表します。
チェックされた例外はJavaプラットフォームの間違いであり、それらを非常に控えめに使用するか、まったく使用しないと考える人がたくさんいます。あなたはグーグルを検索することによってこの議論についてもっと読むことができます。
なぜなら、
次のリンクを確認してください。