なぜ例外処理をカスタマイズするのですか?

Javaの例外クラス構造から見ると、すべての例外クラスは変換可能クラスを継承し、変換可能クラスはトップクラスクラスオブジェクトのサブクラスである.また,Throwableを継承するクラスにはErrorとExceptionがあり,Errorは開発者が予想しなかったシステムレベルのエラーであるため,あらかじめ準備が困難である.
逆に、Exceptionは開発者がロジックを追加して処理することができます.
開発の過程で、例外処理のクラス作成時にRuntimeExceptionが継承されていることがわかります.すべてのExceptionがRuntimeExceptionであるわけではありません.まずCheckedExceptionとUncheckedExceptionです.

Checked Exception VS Unchecked Exception

Checked Exception

は例外処理を行わなければならない.

コンパイルステップ

エラー

異常時の取引(ロールバックX)

RuntimeExceptionを除くすべてのException(Ex.IOException)

Unchecked Exception

異常処理

を強制する.
実行ステップ

エラー

異常時の取引(ロールバックO)

RuntimeExcpetion(ex. NullPointerException etc)

CheckedExceptionが発生する可能性がある場合は、try-catch文を使用して処理する必要があります.このセクションでIntelliJを使用すると、IntelliJは赤い線を自動的に表示し、通知します.ただし、UncheckedExceptionは実行段階で発生する可能性のあるエラーであり、丁寧なエラー処理がないと見逃す可能性が高い.しかし、お客様に見てはいけない情報を見せたくない、あるいはお客様に見苦しい間違いを見せたくない場合は、丁寧に処理しなければなりません.(開発者にとって、実装よりも重要なのは安定したサービスを作成することです!)
最初、私がこれらのエラーに遭遇したときも、throw new NullPointerException(「error message」)をこのように処理したことがあります.(当時は例外扱いの誇りがありましたが、今思えば全く統一性がなく、間違いの原因や理由を明確にしていない言葉がフロントを混乱させる可能性があります.)
開発者は、チームメンバーと実装されたビジネスロジックのRuntimeExceptionを個別にカスタマイズする必要があります.この部分はコンパイルフェーズでエラーが発生せず、実行フェーズでエラーが発生するため、より詳細な処理は安定したサービスを作成する良好な開発者の能力だと思います.
今回の実戦種目が始まる前に、選手たちと一緒に例外処理を考えて、使い方を統一することにしました.
私たちが考えている基準は2つあります.それはフロントに統一的で正確な誤った情報を伝えることです.そしてExceptionHandlingの方法をJSON形式で転送します.統合されたエラーメッセージを作成します.ステータスコードまで一緒に伝える方法を決めます.また,@ControllerAddiceと@RestControllerAddiceを用いてException Controllerを作成し,従来の小型プロジェクトよりも可読性と使いやすさの方法で異常処理を行うことができる.
(以下、本プロジェクトで使用するException処理方式コードです.)

public class UserNotFoundException extends RuntimeException {
    public UserNotFoundException() { super(); }
}

@RequiredArgsConstructor
@RestControllerAdvice
@ControllerAdvice
public class ExceptionController {
@ExceptionHandler(UserNotFoundException.class)
    public ResponseEntity<Fail> UserNotFoundException(UserNotFoundException e) {
        return new ResponseEntity<>(new Fail("닉네임이 존재하지 않습니다."), HttpStatus.BAD_REQUEST);
    }
}