에러가 점점 다양해집니다.
JWT에서 refresh-token이 추가되면서 프론트에서 에러를 좀 더 세분화하여 구분을 해야하기 때문에 이를 위해 처음에는 토큰 에러일 경우, 응답 코드를 기존 int 형이 아닌, string 형으로 응답을 주도록 설계했습니다. (프론트에서도 처음에는 이렇게 요구하였기 때문입니다)
하지만 에러가 많아지기 시작하면서 구분하기가 어려웠습니다. 동일한 HTTP 상태코드를 가지더라도, 발생한 위치와 시점에 따라 다 다르기 때문에 이를 구분할 필요가 있었습니다. 그래서 에러 코드를 세분화해야한다는 생각을 하였습니다.
그리하여! 지난 10월 28일 회의에서 에러 코드를 세분화하자 의견을 제시하였습니다!
세분화 방향
HTTP 상태 코드는 팀원들과 상의하여 결정하였습니다. 기존에 BaseException 에 정의된 에러 코드들을 모두 재검토 했습니다. 다음으로 error 객체에 담길 code 값을 결정해야 했습니다.
규칙 정의
내부적으로 정할 코드가 필요했습니다.
-
에러가 10개가 넘어갈 수 있기 때문에 하나의 집합에는 0~99를 할당하는 것이 확장성을 고려하면 좋을 것 같다고 생각했습니다.
-
유저-토큰의 경우, 비슷한 기능을 합니다. 유저의 경우에는 로그인, 회원가입에 대한 에러가 존재하고 토큰의 경우에는 유효성 검증 오류 등이 존재합니다. 비슷한 기능을 하므로, 100번대로 세부 기능을 분리하는 것이 좋다고 생각했습니다.
-
현재 도메인을 살펴보면 크게 유저, 결제, 포트폴리오, 매칭, 견적서, 리뷰, 찜 으로 7가지가 존재합니다. 그리고 공통적으로 발생하는 데이터베이스 오류, 접근 불가 오류로 크게 분류하면 8가지 영역이 있습니다. 따라서 1000번대 번호로 이를 구분하면 좋을 것 같다고 판단하였습니다.
이렇게 판단하였고, 받아들여져서 이렇게 진행하게 되었답니다!
즉
- 1000번대 = 공통 에러 대역
- 2000번대
- 2100번대 = 유저 에러
- 2200번대 = 토큰 에러
- 3000번대 = 결제 에러
- 4000번대 = 포트폴리오 에러
- 5000번대 = 매칭 에러
- 6000번대 = 견적서 에러
- 7000번대 = 리뷰 에러
- 8000번대 = 찜 에러
- 9000번대 = 추후 도메인이 추가될 경우 사용
포트폴리오 내에서도 이미지, 가격 등등이 분리되어 있기 때문에 ... 이건 다음 회의에서 의논해야할 것 같습니다.
그리하여
에러 세분화 완료! 다음은 JWT 보안 강화 .....
