Custom Exception, ExceptionHandler 설계에서 나쁜 코드에 대한 고민과 리팩토링 과정

1. 문제 상황

---

기존 코드 흐름

@Getter
public enum ErrorCode {
    DUPLICATED_LONGIND("0101", 이미 사용중인 아이디(학번) 입니다.)"),
    ...

public DuplicatedLoginIdException extends RuntimeException {
	public DuplicatedLoginIdException() {
    }
}

# SignupService
public void signup(LoginReq req) {
	...
    throw new DuplicatedLoginIdException();
}

@RestControllerAdvice
public class ControllerAdvice {

    @ResponseStatus(HttpsStatus.CONFLICT)
    @ExceptionHandler(DuplicatedLoginIdException.class)
    public ErrorResponse duplicatedLoginIdEXHandler(DuplicatedLoginIdException e){
        return new ErrorResponse(ErrorCode.DUPLICATED_ID);
    }
}

위와 같이 예외를 각각의 에러상황에 거의 1대 1로 Custom Exception class를 만들고 에러에 대한 응답 HttpStatus나 ErrorCode는 Member의 ControllerAdvice에서 예외 핸들러를 또 예외마다 하나씩 등록하는 방식을 사용했었다.

이런 구조로 하다보니 코드를 다 작성하고 보니 아래와 같이 Member Aggregate에 관련한 예외만 12개가 생성되었고 다른 도메인에서 발생한 예외를 합치면 40개가 넘는 CustomException과 이 예외를 다룰 ExceptionHandler 또한 40개가 생성되게 되었다.

코드를 짜면서 계속 이렇게 하면 관리가 너무 어려울 것 같은데라는 생각은 계속했지만 계속 엉망인 코드를 작성하고 말았다. 

Effective Java 책이나 다른곳에서는 표준 예외를 사용하고 메시지를 이용해서 상황을 이해하게끔 해도 가독성과 관리가 용이하다고 하지만 Spring이나 Jwt 관련 예외들만 봐도 이미 Custom Exception을 생성해서 사용하고 있고
내 생각에는 커스텀 예외를 사용하는것이 훨씬 가독성이 좋다고 생각했기에 커스텀 예외를 사용하는 방식은 유지하고 리팩토링을 통해 구조를 개선하기로 하였다.

이번에 이 Custom Exception, Exception Handler, ErrorCode를 함께 리팩토링 시도하였고 만족할만한 결과가 나온 것 같아 정리한다.

 

2. 문제 해결

---

점진적으로 리팩토링하였습니다.

✏️ 1차 시도  - 부분 성공

1. ErrorCode에서 HttpStatus까지 관리하도록 변경. 

@Getter
public enum ErrorCode {
    DUPLICATED_LOGINID(CONFLICT, "0101", "이미 사용중인 아이디(학번) 입니다.)"),
    ....
    
    private final HttpStatus httpStatus;
    private final String code;
    private final String message;

    ErrorCode(final HttpStatus httpStatus, final String code, final String message) {
        this.httpStatus = httpStatus;
        this.code = code;
        this.message = message;
    }
}

 

 

2. 커스텀 예외들의 추상 슈퍼 클래스를 생성

@Getter
public abstract class AbstractErrorException extends RuntimeException{
    private final ErrorCode errorCode;

    public AbstractErrorException(ErrorCode errorCode) {
        super(errorCode.getMessage());
        this.errorCode = errorCode;
    }
}

public abstract class AbstractBusinessLogicException extends AbstractErrorException{
    public AbstractBusinessLogicException(ErrorCode errorCode) {
        super(errorCode);
    }
}

public class DuplicatedLoginIdException extends BusinessLogicException {
    public DuplicatedLoginIdException() {
        super(ErrorCode.DUPLICATED_LOGINID);
    }
}

 

 

3. 전역적으로 추상 커스텀 예외에 대한 하나의 Exception Handler 등록

@RestControllerAdvice
public class GlobalExceptionHandler {
	....

    @ExceptionHandler(AbstractBusinessLogicException.class)
    public ResponseEntity<ErrorResponse> handleBusinessLogicException(AbstractBusinessLogicException e){
        ErrorCode errorCode = e.getErrorCode();
        ErrorResponse response = new ErrorResponse(errorCode.getCode(), e.getMessage());
        return new ResponseEntity<>(response, errorCode.getHttpStatus());
    }
    ...
}

위와 같이 ErrorCode를 커스텀 예외 내부에 숨겨서 애플리케이션 로직에서는 예외의 이름을 통해 구체적인 예외 상황을 가독성 좋게 확인 가능하고 에러코드와의 의존성은 끊어서 괜찮다고 생각했다.

또한 추상 슈퍼 예외 클래스를 만든 이유는 GlobalControllerAdvice를 통해 전역적으로 하나의 ControllerAdvice를 가지고 커스텀 예외의 부모 클래스에 대해서 ExceptionHandler를 등록하면 하나의 예외 핸들러로 모든 커스텀 예외에 대해서 처리할 수 있게 되므로 중복 코드가 발생하지 않는다.

확실히 예외 핸들러도 공통으로 관리할 수 있고 좋은 시도였다고 생각한다.

하지만 결론적으로 Custom Exception의 개수는 줄어들지 않았다. 계속 개선해 나가 보자!

 

✏️ 2차 시도 - 성공!

1차 시도에서 했던 추상 슈퍼 예외 클래스 방식과 Global Exception Handler 방식도 유지하고
Custom Exception의 개수를 줄여 여러 곳에서 재사용할 수 있는 방법을 생각해 봤다.

예외 이름들을 보니 DuplicatedXXException, NotFoundXXException 등 상황이 비슷한 것들이 꽤 많았다.
그래서 상황에 맞는 예외의 가독성은 지켜주더라도 비슷한 것들끼리 또 슈퍼 클래스를 생성하고 ErrorCode를 애플리케이션 코드 쪽에서 예외를 발생시킬 때 예외에 넣어주는 방식으로 진행해 보았다. 

중복에 대한 예외가 아이디 검증, 이메일 검증, 예약 시 등등 여러 곳에서 사용하고 있었다.
따라서 DuplicationException으로 재사용성을 높였다.

public class DuplicationException extends AbstractBusinessLogicException {
    public DuplicationException(ErrorCode errorCode) {
        super(errorCode);
    }
}

# SignupService
public void signup(LoginReq req) {
	...
    throw new DuplicationException(ErrorCode.DUPLICATED_LOGINID);
}

위와 같은 방식으로 다른 예외도 공통화하였다.

더 줄일 수도 있지만 최대한 예외를 읽는데 가독성을 헤치지 않을 정도로 추상화하였고 총 12개의 구체 커스텀 예외로 줄어들게 되었다.

40개 -> 12개는 큰 변화였고 좋은 리팩토링 과정을 경험했다고 생각한다.