このような質問は、おそらくプログラマーがプログラムで何をしようとしているのかに依存することを知っていますが、学校では、（クラス）を投げたりキャッチしたりせず、ランタイムの種類に固有のサブクラスの1つをスローするように教えられましExceptionた予想されるエラーが発生する可能性があります（例：IllegalArgumentException）。しかし、私は現在作業中であり、「現実の世界」では、以前のプログラマーがメソッド内のすべてのものを投げたり、より具体的なサブクラスの1つではなく、そのようにExceptionキャッチしたりするコードに多くのシナリオがあります。Exception
だから私は疑問に思っています、このようなすべてを投げて捕まえるのは大丈夫ですか、そうするのは悪いプログラミングですか？
それを行うのは間違いではありませんが、デバッグ作業を非常に困難にする可能性があります。多くの人が例外クラスをキャッチし、Exception.Messageをログに記録します。詳細が十分ではなく、特にライブコードなどを常に実行できるとは限らない大規模なシステムで作業している場合は、面倒な作業になります。
私は特定の例外をキャッチしてそれに応じて処理する傾向がありますが、Exceptionクラスもキャッチして、今後すべての例外が確実にキャッチされるようにします（オブジェクトは、将来のフレームワークバージョンでより多くの例外を含むように変更される可能性があります）。
私の考えでは、例外を処理する方法は、作成するアプリケーションのタイプにも依存する必要があります。たとえば、ある種のフレームワークまたはライブラリを開発している場合、エラーメッセージを印刷したりログに記録したりしないでください。例外を処理するためにフレームワーク/ライブラリを使用している他の開発者の責任であるため、それらをスローします。彼らがあなたのコードを使用しているときは優雅に。
ある種のフロントエンドアプリケーションを開発している場合は、例外処理をより慎重に行う必要があります。可能であれば、独自の例外クラスを使用することをお勧めします。これは、後でアプリケーションのバグや実行時の問題を特定するのに役立ちます。例外を処理するときは、常により具体的な例外から一般的な例外に移行する必要があります。最後に、「Exception」スーパークラスの例外を処理して、アプリケーションがクラッシュしないようにする必要があります。できれば、アプリケーションのメインエントリポイントにtry-catchブロックを含める必要があります。エラーをログに記録する例外の処理で何が起こるかは、後でエラーを診断するときに良い習慣です。
あなたが学んだように、それは悪い習慣です。
ルールの主な例外の1つは、トップレベルの例外ハンドラー（未処理の例外をキャッチするため）です。これの目的は、例外をログに記録して、後で開発者が読み取ってアプリケーションを修正するために使用できるようにすることです（通常は再スローします）。アプリケーションをクラッシュさせるために-一貫性のない状態のままにするのではなく）。