Spring) 유효성검사2 - 예외처리

지난 포스틍 Spring- 유효성 검사와 이어진다.

유효성 검사를 할때는 에러를 관리해야한다.

Controller에 아래와 같은 join메소드가 있다.

@PostMapping("/join")
    public String join(@Valid UserRequest.JoinDTO requestDTO, Errors errors){
        System.out.println(requestDTO);

        if (errors.hasErrors()) {
            for (FieldError error : errors.getFieldErrors()) {
                throw new Exception400(error.getDefaultMessage()+" : "+error.getField());
            }
        }

        return "redirect:/loginForm";
    }

위 그림은 클라이언트의 요청이 들어왔을 때, request와 response의 흐름도를 간략하게 표현했다.
왼쪽부터 필터 - 디스패처서블릿 - Controller - Service - Repository -DB다.

만약 request가 Repository에서 예외가 발생했다면 1. return이나 2. throw로 반환할 수 있다. 하지만 return은 계속 호출자를 불러야 하기에 번거롭다.

throw를 통해 반환한다면 디스패처 서블릿이 @ControllAdvice가 붙은 클래스에 해당 throw를 던져준다. 아래는 그 예시이다.

@ControllerAdvice //디스패처 서블릿이 예외를 낚아채서 ControllerAdvice가 붙은 클래스를 호출함.
public class MyExceptionHandler {

    @ResponseBody //view가 아니라 메세지를 리턴하기 위함.
    @ExceptionHandler(Exception400.class)
    public String ex400(Exception400 e){
        return Script.back(e.getMessage());
    }
}

public class Exception400 extends RuntimeException{

    public Exception400(String msg) {
        super(msg);
    }
}

Excection400은 RuntimeExcection을 상속하여 임의로 생성한 에러 클래스다.

그렇기 때문에 join에서 에러가 발생하면 Script.back(e.getMessage());가 실행되게 된다.

위와 같은 예외처리는 500번으로 할 수도 있고, login, 회원가입 등 여러 코드에서 사용될 수 있다. 하지만 같은 코드를 반복하는 것은 불필요한 오버헤드를 유발한다.

다음 포스팅에 이를 AOP를 공부하며 해결하고자 한다.