Java でかなり複雑な小さなゲーム (ソリティア、本質的には Windows 版と同様) を実行していますが、まだ多くのエラー処理を行っていません。
クラス全体のほぼすべてのメソッドは、初期コンストラクター (最終的には main())、paintComponent() メソッド、またはマウス イベントによって呼び出されることになります。だから、私の質問は、すべての下位レベルのメソッドで「throws Exception」を使用し、トップレベルのメソッドでのみ try/catch を実行してすべてのエラーを一度にキャッチするのは悪い習慣ですか? (例: 3 つの try/catch - ペイント用、マウス イベント用、メイン メソッド用)。
これにより、その場で簡単にエラーに対処できないことはわかっていますが、とにかくそれを行うつもりはありません。私のエラー処理は、ログへの書き込み、ユーザーへの通知、およびプログラムの強制終了で構成されます。これを念頭に置いて、この方法でエラー処理を行うことで何か悪いことはありますか?
それは、状況にどのようにアプローチしたいかによって異なります。
可能性のある例外をキャッチしたいだけで、ハンドラーコードを気にしない場合は、単に「例外をスローする」を使用できます。これも悪いことではありません。すべての関数をカバーする try-catch ブロックのようなものです。
特定の例外に対して特定のコードを記述したい場合は、try-catch ブロックを使用して、各ハンドラーに適切なコードを記述する必要があります。
あなたの言っていることに基づいて、キャッチされた例外はユーザーに通知してアプリケーションを終了するだけです。この場合、最初のアプローチを使用できます。これは必ずしも最良のアプローチではなく、アプリケーションを強制終了するわけでもありませんが、それがあなたの戦略である場合は、各関数に「スロー」を使用できます。
それが役立つことを願っています!
エラーが発生した場合にこれだけを行いたくない場合は、そのようにすることは完全に理にかなっています。これにより、コードの重複や関連コードの分散がなくなります。ただし、将来的に物事の仕組みを変更することを考えている場合 (これが発生する可能性がある場合)、可能な限りキャッチを下げることをお勧めします (おそらく、例外の必要性をまったく排除し、ログインしてすぐに終了するだけです）。
例外の内部フィールド (具体的messageには、構築時に設定できる) を使用する場合、3 つの異なる catch ブロックの必要性を排除し、1 つだけを使用することもできます (もちろん、エラーが発生した場合の実際のアクションによって異なります)。
私はしません - 大きな理由は、カプセル化を壊すことです。この場合にこれが重要な理由は、エラー処理コードに次の 2 つの先物のうちの 1 つがあるためです。
私の考えでは、最良の構造は、エラーをキャッチし、ログに記録し、ユーザーに警告し、可能な限り終了することです。マウス処理コードが終了できないということはありませんよね?
実際、どこからでも呼び出すことができるエラー ハンドラー クラスを作成し、通知とログを処理します。次に、例外ハンドラーは、表示/ログするメッセージを入力するだけで、他のすべてのコードが共有されます。すべての関数の最後に追加するよりも、このクラスにデリゲートするための入力コストが少なくて済みます。throws Exception
トップレベルのハンドラーが必要な場合は、予期しない実行時エラーをキャッチする必要があります。これにより、ログに記録して、デスクトップにダンプするだけでなく、エラーのためにプログラムが実際に終了していることをユーザーに示すことができます。他のすべてのエラーは、たとえ単に救済したいだけであっても、可能な限り「例外が意味を持つ場所」の近くでキャッチする必要があります。
常にプログラムを終了するほどエラーが深刻な場合は、代わりに RuntimeException をスローする方がよい場合があります。これらは回復不能なエラーを示すために使用され、どこにでも「スロー例外」を置くことによる問題を回避します。とにかく、RuntimeExceptions のハンドラーを用意して、エラーが発生した場合にユーザーフレンドリーなエラー レポートを提供する必要があります。
チェック例外をスローする場合は、できるだけ具体的にする必要があります。例外をスローしてキャッチすると、スローされた他の例外 (RuntimeExceptions を含む) のうち、意図せず別の方法で処理された可能性があるものを隠すことができます。一般的な例外をスローしたい場合は、いつでも独自の例外クラスを作成して代わりにスローできます。
例外処理はコンテキストに依存する可能性があるため、すべてを処理する 1 つの方法はありません。ユーザーがボタンをクリックしてファイルを開き、読み込み中にエラーが発生した場合は、IOException を UI レイヤーまでスローして、そこにエラー メッセージを表示しても問題ありません。一方、一時ファイルの作成中の IOException は、別のディレクトリで再試行することにより、下位で処理できます。
ほとんどの場合、あなたが説明していることと同じことをします。あなたが基本的にやっていることは、Java が持っているばかげたチェック例外を回避することです。どこにでも「throws Exception」を追加する必要さえないはずです。
他のユーザーが使用する API に取り組んでいる場合、さまざまな方法でさまざまな例外を処理したい場合に何が起こっているかを示すために、特定の例外を作成することがあります。