Javaプログラムを書くとき、例外はキャッチされるように促され、いくつかの例外は強制的にキャッチする必要はありません。私のような他の言語から転校した人は確かに少し混乱しているので、私はそれを私の理解で再解釈します。
例外のベースクラスは例外であり、例外サブクラスにはruntimeexceptionおよびその他の例外が含まれます。これらの他の例外はチェックされた例外と呼ばれ、runtimeexceptionは未チェックの例外と呼ばれます。
名前を見るだけで、Javaは、プログラムを安定して実行できるように、開発者に既知の例外をキャッチするように促すことは簡単ではありません。コンパイラは、すべてのタイプまたはメソッドが例外をスローする可能性があることを知っており、特定のタイプまたはメソッドを使用する場合、コンパイラは既知の例外をキャッチするように促します。これらのコンパイラに知られている可能性のある例外は、チェックされた例外です。たとえば、ファイルストリームを閉じると、IOExceptionは既にスローされる可能性があることを密接な方法で述べており、コンパイラは例外をキャッチする必要があることを促します。 runtimeexceptionの例外は、コンピレーション段階では知られておらず、たとえば3/0（3で割る）でのみ決定できます。この除数はランニング段階で変更できるため、キャプチャのプロンプトはありません。これらのruntimeexceptionsは未チェックの例外です。
要するに、Javaはプログラムを可能な限り安定させることになります。この説明はより明確でなければなりません。
ポイントに到達しましょう。
プログラムをデバッグしたときに、この状況に遭遇した人もいるかもしれません。理由は2つしかありません。1。例外があるスレッドは、キャッチしているスレッドと同じスレッドではありません。2。プログラムは例外ではなくエラーをスローします。エラーは、例外と同様に、スロー可能なものから継承することは、キャッチされるべきではない深刻なエラーを指します。この説明を見たとき、私はとても愚かだったので、なぜエラーをキャッチしてはならないのか理解できませんでした。エラーが発生するため、プログラムは直接実行されないため、キャッチすることは意味がありません。その後、私の問題は再びキャプチャされていません。実際、この仮定は真実ではありません。なぜなら、エラーが実際に存在する場合、開発環境で問題が発見され、公式環境に公開することは不可能だからです。
悲しいかな、私は長い道のりを歩き、そのような愚かなことをしたので、エラーをキャプチャすべきかどうかを議論しないでください！
私はまだ知識が豊富であり、執筆の目的は全員のガイダンスを得ることです。記事があなたを助けるなら、それは素晴らしいことです。