서론 드디어 마지막이네요. 처음 이 글을 작성하고자 했을 때는 3편까지 쓸 것이라는 생각을 전혀 안했는데..ㅎㅎ 최대한 간단하게 쓴다고 노력해도 역시 욕심은 끝이 없는 것 같습니다. 이번에는 지난번에 학습한 JsonNode를 활용해서 Custom Deserializer를 직접 만들어 볼텐데요, JsonNode가 헷갈리신다면 이전 편를 확인해주시면 감사하겠습니다.🙇 해결해야 할 것 이번 Custom Deserializer를 통해 해결해야 하는 문제는, 1편의 맨 마지막에 나온 두 가지 문제입니다. 본문을 시작하기 전에 간단하게 리마인드 하고 가겠습니다 ㅎㅎ 지금의 예외 핸들링은, 테마, 시간, 멤버를 선택하지 않았을 때 기본 입력값인 등에 의존합니다. 즉 클라이언트 코드에 완전히 의존하는 구조입니다. 예약을 추가할 때 멤버, 시간, 테마 중 2개 이상의 값이 입력되지 않아도 하나의 값만 표시됩니다. 즉 입력되지 않은 모든 값을 예외 메시지에 담을 수 없습니다. 추가적으로, 날짜를 …

이전 편 내용 요약 어노테이션의 검증을 통해 발생하는 예외는 입니다. 테마, 시간 추가의 경우 값을 입력하지 않으면 빈 문자열()으로 JSON에 담겼기에 를 통해 이 발생했습니다. 예약을 추가할 때는 회원, 날짜, 테마, 시간을 입력받습니다. 날짜의 경우 입력하지 않으면 빈 문자열로 요청 JSON에 담기기에() MethodArgumentNotValidException이 발생합니다. 회원, 테마, 시간은 입력하지 않으면 각각 빈 문자열이 아닌 으로 값이 담기고, 이 값을 Long 타입으로 파싱할 수 없습니다. 따라서 역직렬화 과정에서 InvalidFormatException이 발생하고, Jackson은 이 예외를 HttpMessageNotReadableException으로 던집니다. 결론: 하나의 요청에서 다른 타입의 예외들이 발생하는데 이 예외를 한 번에 처리할 수가 없었습니다. Custom Deserializer 시작 지금 현재의 문제를 크게 보면 역직렬화 과정에서 발생…

배경 우아한테크코스의 두 번째 스프링 미션을 통해 처음으로 스프링의 예외 처리를 경험하게 되었습니다. 미션의 요구 사항은 예약, 테마, 시간 생성시 발생하는 예외를 적절하게 처리하는 것이었는데요, 와 것과 같은 예외 처리는 크게 어렵지 않았으나 입력에서의 예외, 즉 입력되지 않은 값 등 값 자체가 잘못되었을 때에 대한 처리가 가장 어려웠습니다. 가장 많이 헤맸던 이유는 요청 상황마다 발생하는 예외 타입이 달랐기 때문인데요, 이번 글에서는 해당 문제와 이 문제를 해결해가는 과정에 대해 기록해보려 합니다. 주의 스프링을 이번에 처음 사용하게 되어, 내용이 매우 부실할 수 있습니다. 이 글은 지식을 전달하는 글이 아닌, 개인의 시행착오 과정을 기록하는 글임을 감안해주시면 감사하겠습니다.🙇 API 구성 API - 관리자가 직접 예약을 추가 관리자가 직접 예약을 추가할 땐, 예약 페이지에서 이미 등록된 회원, 테마, 시간과 날짜를 선택합니다. 이때 회원, 테마, 시간은 DB에 저장된 I…