WHITELABEL ERROR PAGE를 .. 당연히 매우 자주 봤다.
server.error.whitelabel.enabled=false
로 WHITELABEL을 제거하고 사용할 수 있고, 그런 경험도 실제로 존재한다.
(CONTROLLER를 ERRORCONTROLLER를 IMPLEMENTS 받아, 사용해야한다.)
CLIENT가 SERVER에게 REQUEST할떄, ACCEPT라는 헤더가 있다.(나 CLINET는 이런 JSON,XML등으로 보내줬으면 좋겠어 하고 힌트를 주는 헤더 )
BROWSER는 기본이 TEXT.HTML
-> 기본적으로 ACCEPT HEADER를 전송할 수 있다.
이러한 기본 WHITELABEL에, PROPERTIES에 MESSGAE,STACKTRACE등을 켜서, WHITELABELPAGE에서도 확인하게끔 할 수 있다.
CUSTOM ERROR PAGE를 생성하고 싶다.
-> SPRING BOOT에서 미리 약속해놓은 이름으로 완성하는 방식이 있다.
기본적으로 static에/error.html을 넣으면 그 페이지가 작동한다.<굉장히 간단>
조금 더 복잡하게는 http status 별로 만들어줄 수도 있다.
404,405를 묶고 싶다면. resource/template/error/4xx(실제로xx를 넣어야됨).html
@ExceptionHandler -> 예외에 반응하는 ExceptionHandler(갑자기떠오르는 arichtectException<수>)
1. 일반 @ExceptionHandler ->
public ResponseENtit<APIErroReseponse> general (RuntimeException e )
이경우에는, runtime exception이, 다른 exception 까지 잡는다.
2. @ExceptionHandler(RuntimeException.class) -> 특정 예외 clas를 지정해줄수있다.
명확한 이 exception만 잡는다. (이를 상속받는 exception도 잡지 않는다.
-> exception e로 변경하여도 똑같다.
@ControllerAdvice
-> exceptionhandler는 , 특정 controller로 제약된다.
-> global하게 사용할수있다.
api시는 @RestControllerAdvice(basepackage = " 예외를 잡고 싶은 package")
이를 보안하기 위하여 (basepackageclasses = "아무 controller.class") -> 컴트롤러중 대표하는 한개의 controller를
잡는다.
즉, 밑의 내용을 해본 결과, controller단에서 발생하는 exception에 대한 제어라고 볼 수 있다.
@ResponseEntityResponseHandler
-> COntrollerAdvice 안에 넣을 수 있고, 이가 상속받으면 수많은 예외들을 조정할 수 있다.
<스프링측에서 에러를 미리 적어줬다.. 라고 생각하면 될 것 같다>
주로 errorcode를 enum 형태로 생성하여, 코드에 첨부한다.
보통,
dto에 ERRORRESPONSE를 지정해놓고, 그 이후 APIRESPONSE를 생성해준다.
errorcode. 수많은 errorcode들을 한발 빠르게 저장해둔다.
이러한 errorcode에서. 직접 message를 받을 수 있는 getter 생성.
즉 error는,
1. 수많은 error를 enum혹은 다른 type으로 묶어둔다. -> 생성하면서 생성이 불가능할떄 아예 excpetion을 떤지기도 한다.
(헤당 error는 , messgae라는 내부로 어떠한 것인지를 표현하는 게 좋다)
미리 error을 정의한다.
2. error응답에 따라 exception을 발생시킬, runtimeexception을 상속받은 class를 생성한다.
생성된 error exception들을 모아놓은 경우.
3. 해당 errorcode를 받아서, 생성되는 응답 객체를 만든다 .
4 data응답 객체를 생성할떄, 에러응답객체가 포함되는 형태로 만든다.
그 과정에서 생성자를 숨기는 등, 많은 복잡함이 있지만, 이러한 과정을 통해 협업에서의 부드러운 작업을 유도한다.
Controller 단 구현
HTTPSTATUS의 STATUS가 있다. 이를 위해서 ERRORCODE를 STATUS에 맞춰서 생성할 수 있는 생성자를 구현해 두었었다.
또한 , map을 사용해서 이동과 동시에 특정 객체를 return하고자 한다.
해당 구현을 완료하였다. 4몇으로 들어온 친구들은. errorcode의 bad_request로 두고 이러한 열거형 errorCode를 생성한다.
* 잠깐 tip <of?>
of 는 더이상 인스턴스를 생성할 필요없이 바로 return할때 사용.
--controller 예시 --
apieventController 내부에서, error가 발생하면 이를 handle 해준다.
<이 class에서만 작동함에 주의하라>
해당 내용. exception이 발생하면, 위에서 @ExceptionHandler에서 해당 exception을 낚아챈다.
낚아채서 해당 exception을 가져와서 그 exception의 errorcode를 대입한다.
이와 같이 runtimeexception이 발생할때, 해당 exception을 generalexception이 상속해서 발생하기로 약속했기 때문에 가능
허나 ERROR를 전송할때는, JSON형태로 내려오게 설계하는것이 올바르고, 그렇지 않을때는
VIEW로 내려보내는것이 더 괜찮은 방법이라고 할 수 있다.
양이 계속 늘어난다. 잠깐
RUNTIMEEXCEPTION은 - > GENERALERROR로 받았다.
현재 우리는, 특정 ERROR 발생만을 다뤘다.
이제 1. GENERALERROR를 CONTROL 하고, 2. GENERALERROR외의 ERROR를 CONTROL하자.
이를 apiversion에도 생성한다.
즉 현재 controller 단의 error -> baseexceptioncontroller (controlleradvice). apicontroller단의 error-> apiexcpetioncontroller로 잡는다.
이러한 ERROR 말고도, SPRING 상의 ERROR도 발생할 수 있다. 이것도 잡아줘야 한다.
쉽게 하는 방법.
해당 exceptionhandler이다. -> spring boot상의 error->exception을 잡아줄 수 있다.
-> 재구현이 필요하긴 하다
재구현이후, super로 다시 같은 객체에 넣어주면, 내가 변경해서 다시 해당 객체에 넣어주는 형태로 구현이 가능!
길었다. 총정리
exception을 잡는것은 굉장히 어려운 일임을 일단 깨달았다.
가장 먼저 어떠한 exception들이 발생할 수 있는지를 알아야 진행이 가능하다.
허나 기본적으로는 발생할수 있는 error들을 정리 -.Exception 구현 -> error용 response 구현.
그 이후 각 api관련 controller 별, 다른 controller 별 발생할 수 있는 exception들을 구현하는 방식으로 진행한다는 것을 꺠달았다.
