예외 정의에 대한 논의

[unikal1]

현재 커스텀 예외는 다음과 같이 구현되어 있습니다.

// 모든 커스텀 예외의 부모 추상 클래스
public abstract class BaseException extends RuntimeException {
    private final ErrorCode errorCode;

    protected BaseException(ErrorCode errorCode) {
        super(null, null, false, false);
        this.errorCode = errorCode;
    }

    protected BaseException(ErrorCode errorCode, String logMessage) {
        super(logMessage, null, false, false);
        this.errorCode = errorCode;
    }
}

//모든 ErrorCode enum 클래스의 부모 인터페이스
public interface ErrorCode {
    String getCode();

    HttpStatus getHttpStatus();

    String getMessage();
}

이 둘을 기반으로 다음과 같은 예외와 예외 코드를 생성합니다.

//인증/인가 및 멤버 관리에서 발생하는 예외
public class AuthException extends BaseException {
    public AuthException(AuthErrorCode errorCode) {
        super(errorCode);
    }

    public AuthException(AuthErrorCode errorCode, String logMessage) {
        super(errorCode, logMessage);
    }
}

//AuthException에서 사용하는 에러코드. 해당 부분을 논의해야 합니다.
@Getter
@RequiredArgsConstructor
public enum AuthErrorCode implements ErrorCode {

    UNKNOWN_USER("10-1", HttpStatus.NOT_FOUND, "can't find user")
    ;

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

    @Override
    public String getCode() {
        return code;
    }

    @Override
    public HttpStatus getHttpStatus() {
        return status;
    }

    @Override
    public String getMessage() {
        return message;
    }
}

다음과 같이 도메인 별로 AuthException 과 같은 예외 클래스 및 그에 따른 에러 코드를 enum으로 관리할 예정입니다. 이때 다음과 같은 논의가 필요합니다.

1. code 부분(ex - 10-1이라 명시된)의 명명법
2. message 형식
3. logMessage 형식
4. 어떤 범위로 예외를 쪼개야 되나. (세세하게 혹은 범위를 넓히되 message로 구체화할지)
5. 어떤 예외가 필요할지, 또한 추후 새로운 예외 코드가 필요할 때 어떤 방식으로 상의하여 결정할 것인지

[sjhlko]

괜찮은 방법으로 구현하신것 같아요

코드 명명의 경우 기능정의시 기능이 속한 도메인, 기능코드, 발생할 수 있는 성공/에러를 정의하여 순서대로 코드를 부여하는 식으로 하시면 될 것 같아요
예를 들면 A(도메인)01(해당 기능 코드)-E(성공/실패 여부)01(해당 케이스에 대한 인덱스) 이런식으로 알아볼수 있게요 (이렇게 하라는건아님)
ex) A01-S01 / A01-E01

저걸 처음부터 잘 정하고 가야된다고 생각하면 기능 정의를 정확히 하고 해당 성공/실패 케이스 정의부터 해야할 것 같네요~~
메시지 형식이나 로그 메시지 형식은 해당 응답 내용의 논리적 내용을 내포하면 좋을 것 같네요
ex ) CODE : A01-S01 (사용자 도메인 회원가입 기능/중복 회원의 경우의 응답 코드라고 가정) Message : 이미 존재하는 회원입니다.

대충 포함해야되는 필수적인 요소들을 예시로 나타낸거라서 영어로 할지 한국어로 할지 코드는 어떤 규칙으로 세울지는 컨벤션처럼 정해야 할 것 같아요~~

[s0o0bn]

우선 위 내용은 좋은 의견이라고 생각합니다. 또한 구현해주신 예외 처리 방식도 좋습니다.
저는 이전 프로젝트에선 성공 응답은 그냥 클라이언트에 전달하는 데이터 자체만 반환했는데, 정희님 말씀대로 예외 응답과 동일한 형식으로 맞추는 게 적절해 보입니다.

(2, 3) 에러 혹은 로그 메세지의 경우 모니터링 목적으로 필요한 경우가 많다고 생각해서, 개인적으로는 한글이 좀 더 직관적으로 읽힐 것 같습니다.
(4) 저도 지금 구현 예시처럼 각 도메인 별로 예외 클래스를 두고, 세부적인 예외(사용자의 잘못된 입력, 존재하지 않는 데이터 조회 등)을 ErrorCode로 구분하는 방식을 주로 써오긴 했습니다. 이 내용을 말하신 게 맞나요?

이때 인증과 사용자는 구분하긴 했습니다. (토큰 만료, ID/PW 틀림 등 vs 사용자 없음 등)

(5) 4번에서 언급한 것처럼 기본적인 404, 401 상태코드에 해당하는 예외는 도메인마다 필요하게 될 것 같습니다.
그 외에 정책과 관련된 예외(토큰이 없는데 다마고치 행동 관련 요청을 했다거나)는 사전에 다 정해두기는 현실적으로 어렵기도 하고, 정책이라는게 개발하면서 바뀔수도 있다고 생각합니다.
그래서 일단 그때그때 담당자가 기능 구현하면서 정책 관련 의견이 생기면 디스커션을 열거나 회의 안건으로 올려서 결정해도 좋을 것 같습니다.

[unikal1]

그렇다면 응답 형식을 다음과 같이 하는 건 어떨까요

{
    "code" : (domain)-(code),
    "success" : true or false,
    "data" : {
        "id" : 1,
        "username" : "username",
        "password" : "12345"
    },
    message : "message"
}

굳이 성공 여부를 개별적으로 관리하는 까닭은, 값을 추출하기 편하고 가독성이 좋다... 정도가 있겠네요. 이때, 만약 에러 발생 시에는

{
    "code" : (domain)-(code),
    "success" : false.
    message : "can't find user"
}

이런 방식이 될 거 같아요.
또한 메시지는 개인적으로 영어가 맞다고 보긴 하는데, 도메인, 클래스 부터 시작해서 사용하는 용어 대부분이 영어로 이루어져 있다 보니까 결국 혼용해서 사용하다보면 이름에서부터 혼동이 올 수 있다고 생각하거든요. (즉, 영어는 실제로 해당 객체/엔티티/데이터를 가리킬 수 있지만 혼용해서 사용한다면 이를 한글로 표현할 시 명칭에 있어서 혼란스러움이 생길 수도 있을 것 같다는 거죠)

직관적으로 읽히지 않을 정도의 복잡한 예외 상황인 경우, 이를 설명하기 위한 문자열이 너무 길어지고, 이를 예외에 담는 건 코드 자체의 가독성이 떨어지다보니, 차라리 이런 경우 해당 코드의 예외를 문서에서 참고하라는 메시지를 남기는 건 어떤가요.

마지막으로 예외를 정하는 것은, 추후 도메인을 설계할 때, 기본적인 예외 상황을 고려하여 에러 코드를 편성해 두고, 추후 개발 시 새로운 에러 코드가 필요하다면 상의 후에 결정하는 걸로 하죠.

[sjhlko]

괜찮은 방식입니다~ success: true 도 괜찮지만 보편적으로 표현하려면 status : Success/Error 이런식으로도 할 수 있겠네요~

[s0o0bn]

좋습니다~

저도 boolean보다는 직접적으로 성공/실패 여부를 나타내는 게 좋아 보입니다.
그리고 영어 메세지 관련 말씀 주신 방식 괜찮은 것 같습니다.

[unikal1]

{
    "code" : (domain)-(code),
    "status" : success,
    "data" : {
        "id" : 1,
        "username" : "username",
        "password" : "12345"
    },
    message : "message"
}