[SW마에스트로] 프로젝트 중 설계한 예외 처리 아키텍쳐

현재 개발자 사이드 프로젝트 팀 매칭을 하고
매칭한 팀끼리 멘토링 받을 수 있는 플랫폼을 제작하고 있습니다 

 

개요

나는 중간 발표때 시연을 해야해서 급하게 결과 화면을 뽑아내기 위해 "예외처리, 테스트 코드"를 작성하지 않고 API만 주구장창 개발하였다. 나와 팀원분 둘다 첫 프로젝트라 예외 처리를 하는 방법을 잘 몰랐었는데 시간이 많이 들 것 같아 중간 발표 이후에 만들기로 했던것이다.

 

나중에 알고보니 정말 중요한 부분을 빼놓고 개발한것이었다

 

이제 중간 발표(8/26)가 끝났으니 1차 배포 전까지 안정적인 서비스를 만들기 위해 예외처리를 적용하고자 한다.

 

예외 처리 설계

파일구조

 

1. 먼저 예외를 공통으로 처리 할 advice 클래스 GlobalAdvice를 만들 예정이다. 그리고 GlobalAdvice 클래스 안에서 @ExceptionHandler를 이용하여 발생한 에러를 캐치하여 분기한다.

 

2. exception은 모든 예외에서 공통으로 존재해야 하는 정보를 CustiomException에 넣어 놓고 추가 정보가 필요할 경우 CustomException을 상속한 새로운 예외 클래스를 만들것이다. 추가로 400, 401, 404 에러를 파일로 분리하여 각각 CustomException을 상속받게 하고 그 밑에 짜잘한 에러들은 400, 401, 404 에러를 상속 받아서 사용할것이다.

 

3. ErrorCode에는 실제 에러 정보가 Enum 형식으로 들어갈 예정이다. (code 부분은 백엔드 팀원분과 협업할때 편할 것 같아 추가하였다)

 

 

4. ErrorResult는 최종적으로 프론트에게 넘어가는 DTO이다.

{
    "code": "G-004", // (String)
    "message": "토큰이 유효하지 않습니다.", // (String)
    "messageExtra": "TeamCreate" // (Object)
}

 

이런식의 DTO가 나갈 예정이다

 

 

추가로 알게 된점

코딩을 하다보니

1. 예외를 내가 던져서 내가 잡는경우

2. 스프링이 던져준 예외를 내가 잡는경우 가 있는거 같다

 

강의를 들으면서 궁금했던 점과 해결

• 빈 검증은 DTO의 Request에서 주로 사용한다, Entity에 검증을 적용해버리면 비즈니스 요구사항에 따라 검증이 바뀌어야 할때 구현하기 어려워 진다. (관심사의 분리)