ERROR /예외 처리
NULL요건을 지키지 않았거나, 문제가 발생했을때는 어떡할까?
HTTP MESSAGE 중
배열이 비어있을경우 NULL이 아닌 빈 배열을 응답하게 된다.
404,403등의 수많은 ERROR MESSAGE를 보았다.
그 중에 4XX,5XX과 같은 경우에는 항상 동일한 포멧을 RETURN하는 형태로 ERROR처리가 이루어져야 한다.
ERROR에 대한 처리를 MAP 객체를 통하는 방식은, 지양하자.
ERRORRESPONSE를, 별도의 CLASS로 선언하여 객체 형태로 RETURN 하는 것이 좋다.
1. ERROR RESPONSE -> 안에 내부 FIELD로 ERRORCODE를 사용한다 .
2. 그 후의 ERRORCODE는 주로 ENUM 형태로, MESSAGE를 전송한다.
CONTROLLER ERROR 처리 .
주로 @Valid를 사용한다.
Controller의 역할 중하난, request에 대한 @Valid를 진행하는 것이다.
이는 주로 @ControllerAdvice를 사용한다.
(controller들아, 이러한 advice를 활용하여 오류나 exception등을 처리하라는 의미로 인지하자)
해당 코드에는 고의적으로 생성한 문제점이 있다. (lombok 의존성 추가를 안해서.. 지금 내 컴퓨터가 아니다.)
이 문제말고, 현재 모든 exception에 대해 동일한 exceptionhandling을 한다는 문제이다 . 조금 더 구체적으로 가보자 .
이와 같이 , 특정 EXCEPTION에 대해 HANDLING하는 방식도 가능하다.
*그렇다면, 주로 EXCEPTION에 따라 다른 ERRORCODE를 발생하게 , 그 FORMAT을 통일 시켜주는 방식으로 진행하면 되겠음을 깨달았다.
이런 식으로, CONTROLLER를 설게할때 원하는 목표의 EXCEPTION을 보내고 , 이를 ADVICE로 FORMAT을 맞추어 준 다음에 전송하는 방식을 사용하자!
*BuisnessException은?
현재까지는 실제로 이미 존재하는 exception이 발생했을떄 이를 동일 format으로 맞춰주는 역할을 했다.
ex) 유통기한 몇일 이상 쿠폰 발행시 exception 발생. 혹은 기타 등등 이름 '이스터에그'시 회원가입 실패
와 같은 문제들을 해결하기 위해 발생한다.
즉, 비지니스 요구사항에 따른 exception 발생을 위해 진행한다.
이후 class level @validation이나 @valid는, 그 위치와 사용 어노테이션에 따라 발생되는 exception이 다름에 주의하자!