예외 처리

이전에는 , 모든 exception에 대해서 try and catch를 진행했다. 

모든 메소드를 거의 boolean으로 진행해서, 

try /catch or if절로 검사하여 return false방식으로 진행했다.

 

->해당 방식 문제. 

EXCEPTION을 별도로 생성해야 하는 문제가 발생한다. 

+ 실패와 성공 각각을 DTO에 담아야 하는 , 복잡하고 이상한 형태의 구조가 동작된다.

DTO에는 정보에 대한 것 뿐만 있어야하고, 예외등의 문제 관련하여는 존재해서는 안된다. 

 

-> 대부분을 VOID로 단순화하여, 예외를 생성하는 METHOD를 별개로 만든다. 

코드의 간략화 , DTO의 간략화 

 

 

예외만을 확인

 

예외를 던질지 말지를 실제 메소드에서 확인하고 넘어간다 (비지니스 VALIDATION) 

 

이제 던져진 예외에 따라 문제를 해결해야한다. 

-> CONTROLLER LAYER의, @ExceptionHandler(원하는 exception종류, 주로 생성했떤 , dmakerexception)

 

 

문제 이거 고쳤는데 update가 안된것이구 잘 작동한다! 

이와 같이 dto에 error응답을 받기위한 class를 생성해준다. 

 

 

log로 띄우고 ,또 이 응답객체를 return type으로 하였기 때문에, 사용자 입장에서도 

error 문자와 message를 볼 수 있다 .

 

프리미엄 사고싶다... postman으로 맨날 넣는거 너무 귀찮다 ㅠㅡㅠ

이거 말고도, response의 errorcode에도 이를 볼수 있긴 한데, 상세부를 확인하기 위해선 이와 같은식의 설계가 더 효율적일 수 있다. 

 

최근에는 허나, 이런방식 보다는 global exception handler를 생성한다. -> exception안에 dmakerexceptionhandler

 

이와 같이, exceptionhandler를 넣어주고, 여기에 추가로 그냥 EXCEPTION등도 추가할 수 있다. 

앞의 exception은 사용하고, 그 이후에는 valid,또 잘못된 요청에 대한 exception handler

 

기타 모든 EXCEPTION을 처리하는 EXCEPTION HANDLER. 

 

이 모든 것들은  EXCEPTION->EXCEPTIONHANDLER 이후

@RestControllerAdice로 어노테이션하였기 때문에 가능했다. 

 

EXCEPTION에 대하여 여러가지 경우를 상세히 작성하는 것이 굉장히 중요하다! 

우리가 ERRORMESSAGE를 정의한대로 처리하는게 상대방입장에서 수월하다.  

허나 이러한 ERROR MESSAGE를 출력할때, SQL 쿼리등의 문이 예측되는 시작이 되기 떄문에, 이를 방지해야한다. 

 

 결론적으로

앞으로 내가 설계를 할때, 항시 exception에 대하여 유의하고, 언제든 그자리에서 즉시 던질 수 있는 형태의 설계를 진행하도록 해야 겠다.