例外処理

1. [必須] RuntimeException を継承する Java クラス ライブラリで定義されたランタイム例外クラス (IndexOutOfBoundsException / NullPointerException など) をキャッチしないでください。このような例外はプログラマの事前チェックによって回避されます 、プログラムの堅牢性を確保するため。

正の例: if(obj != null) {...}

反例: try { obj.method ( ) } catch(NullPointerException e){...}

2. 【必須】例外は条件分岐に比べて処理効率が低いため、処理制御や条件制御では例外を使用しないでください。

3. [必須] 試してください - コードの大部分をキャッチしますが、これは無責任です。キャッチする際には、安定したコードとそうでないコードを区別してください。安定したコードとは、何をしても失敗しないコードのことです。不安定なコードをキャッチするには、 例外タイプをできる限り区別して、対応する例外を処理するようにしてください。

4. [必須] 例外をキャッチする目的は例外を処理することです。例外をキャッチせず、何も処理せずに破棄してください。処理したくない場合は ## してください。 #例外を呼び出し元にスローします。最も外側のビジネス ユーザーは例外を処理し、例外をユーザーが理解できる

コンテンツに変換する必要があります。 5. [必須] トランザクション コードに try ブロックを配置します。例外をキャッチした後、トランザクションをロールバックする必要がある場合は、手動で

トランザクションをロールバックすることに注意する必要があります。 。

6. [必須]finally ブロックはリソース オブジェクトとストリーム オブジェクトを閉じ、例外が発生した場合は try-catch する必要があります。

注:

JDK 7 の場合は、try - with - resource メソッドを使用できます。 7. [必須]finally ブロック内では return を使用できません.finally ブロック内の return が戻った後、メソッドは実行を終了し、

は try ブロック内の return ステートメントを再度実行しません。

8. [必須] 例外のキャッチと例外のスローは正確に一致するか、キャッチする例外がスローする例外の親クラスである必要があります。

注:

相手がアジサイボールを投げるつもりで実際に砲丸投を受けた場合、予期せぬ事態が発生します。 9. [推奨事項] メソッドの戻り値は null であっても構いません。空のコレクションまたは空のオブジェクトを返すことは必須ではありません。コメントを追加して、どのような状況で null が返されるかを完全に

説明する必要があります。値が返されます。 NPE の問題を防ぐために、呼び出し元は null 判定を実行する必要があります。

注:

この仕様では、NPE の防止は呼び出し側の責任であると明確に述べています。呼び出されたメソッドが空のコレクションまたは空のオブジェクトを返したとしても、呼び出し元は座ってリラックスすることはできず、リモート呼び出しの失敗や実行時例外などのシナリオで null が返される状況を考慮する必要があります。 10. [推奨] NPE の防止はプログラマーの基礎トレーニングです。NPE が発生するシナリオに注意してください:

1) 戻り値の型はパックされたデータ型であり、null の可能性があります。int 値を返す場合は、null テストに注意してください。

カウンターの例: public int f() { return Integer object}; null の場合、自動的にボックス化解除され、NPE がスローされます。

2) データベースのクエリ結果が null になる可能性があります。

3) コレクション内の要素が NotEmpty であっても、取得されたデータ要素は null である可能性があります。

4) リモート呼び出しによって返されるオブジェクトには、NPE 判定が常に必要です。

5) セッションで取得したデータについては、null ポインターを避けるために NPE をチェックすることをお勧めします。

6) カスケード呼び出し obj . getA() . getB() . getC(); 一連の呼び出しにより、簡単に NPE が発生する可能性があります。

11. [推奨事項] コード内で「例外をスローする」か「エラー コードを返す」を使用するか、社外の http/api オープン インターフェイスの場合は 「エラー コード」を使用する必要があり、例外は次のとおりです。アプリケーション内で推奨されます。 Throw; アプリケーション間 RPC 呼び出しの場合は、Result メソッドが優先され、isSuccess、「エラー コード」、および「エラー概要情報」がインストールされます。

説明:

RPC メソッドの戻りに Result メソッドを使用する理由: 1) 例外の戻りメソッドを使用します。呼び出し元が例外をキャッチしない場合は、例外が返されます。実行時エラーが発生します。

2) スタック情報を追加せず、新しいカスタム例外を追加するだけで、エラー メッセージについての独自の理解を追加した場合、呼び出し側

側の問題解決にはあまり役に立ちません。スタック情報を付加すると、呼び出しエラーが多発した場合、データのシリアル化や送信のパフォーマンス低下も問題となります。

12. [推奨] 定義時に未チェック/チェック済み例外を区別し、RuntimeException を使用して直接スローすることを避け、 で Exception または Throwable をスローすることは許可されず、ビジネス上の意味を持つカスタム例外を使用します。 DAOException / ServiceException など、業界で定義されているカスタム例外を推奨します。

13. 【参考】コードの重複を避ける（Don’tRepeatYourself）、すなわちDRY原則。 注: コードを自由にコピー アンド ペーストすると、必然的にコードの重複が生じます。将来変更が必要になった場合は、すべてのコピー

を変更する必要がありますが、これは簡単です。逃すこと。必要に応じて、共通メソッド、抽象パブリック クラス、さらには共有モジュールを抽出します。

良い例: クラス内に複数のパブリック メソッドがあり、それらはすべて同じパラメーター検証操作を複数行実行する必要があります。このとき、次を抽出してください: private boolean checkParam(DTO dto){...}