例外とは、Java (またはその他の) プログラムの通常の実行フローが中断されることです。この違反は、メモリ アクセス違反、ゼロ除算、初期化の問題、不正な命令の実行、またはその他の致命的なエラーによって発生する可能性があります。Java は、このような望ましくないシナリオをすべて適切に処理できますが、開発者がこれらの Java 機能を使用すると、いくつかの問題が発生する可能性があります。
この記事では、Javaでの例外処理がどのように機能するかについては説明しません。読者は、例外階層、チェック済み例外
、未チェック例外
、実行時例外についてはすでによく理解していると思います。ここでは、避けるべき最も一般的な間違いについて説明します。
例外の関係者
実行スレッドが中断されるたびに、それに関する情報がプログラム実行者に返される必要があります。このスレッドは、画面、バッチ タスク、またはその他の方法から開始できます。これらのトリガーはすべて、フロー内で何らかの違反が発生するのを待って、特定の形式のメッセージを送信します。画面ベースのトリガーは、いくつかの技術的な問題があり、サポートに連絡して支援とアドバイスを求める必要があることを優しく知らせてくれます。バッチ プロセスまたはスタンドアロン Java プログラムでは、エンド ユーザーにはまったく理解できない何らかのログの形式でエラー レポートが表示されることを期待する場合があります。しかし、ビジネスパーソンは、自分が理解できる言語でメッセージを受信する必要があります。ユーザーの心の中にある恐ろしい NullPointerException は非常に迷惑です。これらのエラーは、プログラムの誤った使用の結果である場合もありますが、修正が必要な問題である場合もあります。2 番目の重要な利害関係者は、例外によって引き起こされる問題に対処しなければならない人です。この人は、例外が発生したときのプログラムの実際の実行を観察することができません。これは 2 つのことに依存します。1 つは、問題が発生しているユーザーから提供された情報で、2 つ目は、例外が発生したときに生成されるある種のログです。さらに、問題を分析する人はプログラムを作成した人と同じではないため、プログラム開発者は分析に十分な情報を提供する必要があります。プログラム開発者とそのデバッガ間の唯一の通信方法はログです。また、セキュリティ上の理由により、ログ ログには例外発生時のプログラム実行の実際の詳細がすべて含まれていない場合があります。例外処理で考えられるエラーを見てみましょう。中にはかなり愚かに見える人もいますが、人間もいます。これらのエラーが問題を引き起こすまで、それらに注意を払わない人もいます。
空の例外ブロック
これは、例外処理において最も望ましくないエラーの 1 つです。この場合、例外は単純に無視されます。ソリューションには、例外を残すためのコメント行のみが含まれています。
try{ }catch(SQLException sqe){ // do nothing } まれに、データベースがシャットダウンされる最後のブロックなど、例外がスローされることがあります。この場合、それらは無視できます。
try{ }catch(SQLException sqe){ ... ... }finally{ try{ conn.close(); }catch(Exception e){ //leave it. } }
例外メッセージの誤った一般化
この点は主観的なものです。例外をキャッチした後、わかりやすいメッセージの形式でエンド ユーザーに例外を報告できます。元のメッセージが 1 つの一般的なメッセージに変換されると、元のメッセージの詳細が失われる可能性が十分にあります。メッセージはエンド ユーザーに適切な情報を伝え、サポート チームに連絡するときにユーザーが適切なログにログインするだけで情報を提供できるようにする必要があります。
try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new Exception("File Processing Failed",ioe); } 多層アプリケーションでは、各層が例外をキャッチし、新しいタイプの例外をスローします。場合によっては、特定のタイプの例外をキャストすることが絶対に必要になることがあります。 - データ アクセス層 -> DataAccessException を作成します。 - ビジネス実装層 -> BusinessException を作成します。 - アプリケーション サービス層 -> ApplicationServiceException を作成します。 すべてが論理的ですよね。ここでは、ApplicationServiceException と BusinessException のどちらかを選択する必要がある場合があります。これは、どちらも同じ情報を表すことができるためです。これらの例外変換のうちの 1 つは不要と思われます。
StackTrace クラスの破棄
例外を新しい特殊な型に変換するプロセス中に、スタック トレースが消える可能性があり、例外の実際の原因を追跡するのは悪夢のようなものになります。以下のコードでは、元の例外から情報を受け取らずに新しい例外がどのようにスローされるかを確認できます。
try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new MyException("Problem in data reading."); }
例外理由の上書き
各例外メッセージには、例外の理由に関する情報が含まれています。ただし、新しい例外が作成されると、古い例外に関する情報が完全に削除される場合があります。これは、新しい例外がスローされたために StackTrace が削除される可能性がある上記の例に似ています。
特定の例外を検索しない
開発者は例外を処理する際に安全策を講じることを好む場合があります。場合によっては、これが簡単に実行できる場合もあります。ただし、特定の例外の代わりに java.lang.Exception をキャッチすることは受け入れられません。
try{ File file = new File(""); file.getCanonicalPath(); }catch(Exception exe){ throw new MyException("Problem in data reading."); }
不必要なキャッチアンドスロー
例外を別の型に変換する場合、またはエンド ユーザーまたはアナリストへの例外メッセージに情報を追加するのに役立つ場合は、例外をキャッチします。それ以外の場合は、それらをキャッチするのではなく、メソッド シグネチャ内で (throw を使用して) さらに投げ捨てます。
RuntimeException をキャッチする
RuntimeException をキャッチしないようにすることをお勧めします。代わりに、特定の例外をキャッチして処理する方が良いでしょう。
未チェックの例外を見つける
未チェックの例外をキャッチするかどうかは、議論の余地のあるトピックです。NullPointerException と ArrayIndexOutOfBound は、チェックされない例外の最良の例かもしれません。これらの例外をキャッチする代わりに、コードを変更してこれらのシナリオを処理することができます。たとえば、NullPointerException を回避するため、すべての変数が確実に初期化されるようにするため、ArrayIndexOutOfBound 例外を回避するため、正しい長さの配列を定義するためなどです。
例外ログに関する問題
この雑誌は、2 番目に関心のある人、つまり問題を分析している人に役立ちます。開発者がログ ファイルを使いすぎて、アプリケーションのあらゆるレベルでログが作成される場合があります。ログには、例外が発生したレベルで例外が記録される必要があります。例外が発生したことを示す警告を表示し、プログラムの実行を停止または続行するかどうかを提案し、例外をログに記録することを義務付けるのが最適と思われます。
フロー制御例外
例外とは、プログラムの通常のフローが中断されることです。つまり、このフローを中断してエンド ユーザーに通知する必要があります。代替スレッドであるメソッド呼び出しを追加すると、メンテナンスに大きな問題が発生します。
try{ myObject.getValue(); }catch(NullPointerException npe){ alternateMethod(); }
java.lang.Exception のユビキタスな使用
また、あらゆる例外に対して java.lang.Exception を使用することも得策ではありません。代わりに、アプリケーション固有の例外、または最も適切な標準 Java 例外を使用することをお勧めします。
原文：Common Mistakes in Exception Handling 翻訳・音声：Ve4niY
GO TO FULL VERSION