[Spring_4기 본캠프] Spring 심화 - Java Exception | Day 55

1. Enum으로 전역예외처리하기

@Getter
public enum ErrorCode {

    // Basic
    INVALID_INPUT_VALUE(HttpStatus.BAD_REQUEST, "E1", "올바르지 않은 입력값입니다."),
    METHOD_NOT_ALLOWED(HttpStatus.METHOD_NOT_ALLOWED, "E2", "잘못된 HTTP 메서드를 호출했습니다."),
    INTERNAL_SERVER_ERROR(HttpStatus.INTERNAL_SERVER_ERROR, "E3", "서버에 에러가 발생했습니다."),
    NOT_FOUND(HttpStatus.NOT_FOUND, "E4", "존재하지 않는 엔티티입니다."),
    CONFLICT(HttpStatus.CONFLICT, "E5", "이미 존재하는 엔티티입니다."),
    ACCESS_DENIED(HttpStatus.FORBIDDEN, "E6", "접근 권한이 없습니다."),
    
     // Token
    INVALID_TOKEN(HttpStatus.UNAUTHORIZED, "T1", "유효하지 않은 토큰입니다."),
    TOKEN_NOT_FOUND(HttpStatus.UNAUTHORIZED, "T4", "존재하지 않는 토큰입니다"),
    
    // FollowRelationship
    FOLLOW_RELATION_INVALID_VALUE(HttpStatus.BAD_REQUEST, "F4", "잘못된 요청입니다. 자기 자신을 팔로우할 수 없습니다."),
    FOLLOW_RELATION_NOT_FOUND(HttpStatus.NOT_FOUND, "F4", "존재하지 않는 관계입니다."),
    FOLLOW_RELATION_ALREADY_ACTIVE(HttpStatus.CONFLICT, "F7", "이미 팔로우한 친구입니다."),
    FOLLOW_RELATION_ALREADY_INACTIVE(HttpStatus.CONFLICT, "F8", "이미 언팔로우한 친구입니다.")
    ;

    private final HttpStatus status;
    private final String message;
    private final String code;

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

 

자바에서 예외처리를 하는 방법은 여러 가지가 있는데, 그 중에서 나는 저번 팀프로젝트에서 팀원분이 알려주셨던 Enum으로 예외를 처리하는 방법에 대해 알아봤다.

 

<Enum으로 예외를 관리햘 때의 장점>

1. 일관성 : 프로그램 전체에서 동일한 형식의 오류 응답을 제공할 수 있어 API 사용자가 오류 응답을 쉽게 이해하고 처리할 수 있다.

2. 중앙 집중식 관리 : 모든 오류 코드와 메시지가 Enum에 중앙 집중식으로 관리되므로 나중에 메시지를 변경하거나 새로운 종류의 예외를 추가하는 것이 편리하다.

3. 타입 안정성 : 컴파일 타임에 오류 타입을 확인할 수 있으므로 실행 시간 중에 발생하는 문제를 감소시킬 수 있다.

 

즉, Enum으로 예외 처리를 구현하면 애플리케이션 전반에서 일관된 방식으로 에러 응답을 제공할 수 있으며, 컨트롤러나 서비스 로직에서 개별적으로 예외 처리 로직을 작성하지 않아도 되므로 유지보수성과 확장성이 향상된다.

위 코드는 팀프로젝트 당시 팀원분이 만들어 주신 건데, 당시 튜터님의 피드백으로는 커스텀 에러코드가 의미하는 바가 없다는 것이었다. 스프링에서 제공하는 기본 에러코드가 아닌 지정 코드를 사용하려고 한다면 해당 코드를 만든 의미와 패턴이 있어야 한다. User 관련 에러, 401코드 카테고리라면 U1 이런식으로 각각이 의미하는 바가 명확해 다른 사람이 에러 코드만 보고도 어떤 종류의 에러이고 어느 부분에서 실수가 났구나 라는 것을 알 수 있어야 하는데 구현된 상태로는 그런 것을 알 수가 없다는 것이 피드백의 주 내용이었다.

또한 에러 코드를 세분화하면 할수록 좋은 것인가? 도메인별로 발생될 예외를 모두 정의해주는 것이 맞는가? 에 대한 의문이 있었는데, 결론은 '긍정'.

하지만 만약 세분화하려고 하는데 Enum이 아니라 클래스로 각각의 예외를 관리하게 된다면 메시지 수정이 이루어져야 할 때 중복되는 코드가 있다면 일일이 찾아 들어가 수정을 해야하기 때문에 관리와 유지보수가 매우 힘들어진다. 

 

-> 일반적으로 쓰이는 예외는 클래스로 정의하고, Enum을 활용해 도메인별로 세세하게 예외 상황을 정의해주는 것이 가장 좋은 방법이라고 생각된다.