1. 서비스 계층에서 의도적으로 예외를 던지는 방법과 상황을 이해할 수 있다.
2. 사용자 정의 예외(Custom Exception)를 만들 수 있다.
3. 서비스 계층에서 던져진 예외를 API 계층에서 처리할 수 있다.
- 비즈니스적인 예외 던지기(throw) 및 예외 처리
✔︎ 예외를 잡아서(catch) 체크한 후에 해당 예외를 복구 또는 회피 등의 어떤 구체적인 처리를 해야 하는 예외
✔︎ 예시 : ClassNotFoundException
등
✔︎ 예외를 잡아서(catch) 해당 예외에 대한 어떤 처리도 필요없는 예외
✔︎ RuntimeException
을 상속한 예외 (개발자가 코드를 잘못 작성해서 발생하는 오류)
✔︎ 예시 : NullPointerException
, ArrayIndexOutOfBoundsException
등
✔︎ RuntimeException
을 상속해서 개발자가 직접 사용자 정의 예외(Custom Exception)를 만들 수 있음
✔︎ 서비스 계층의 비즈니스 로직에서 발생하는 다양한 예외를 던질 수 있고, 던져진 예외는 Exception Advice에서 처리
✔︎ @ResponseStatus
애너테이션
@ResponseStatus
로 HttpStatus를 지정해서 사용✔︎ ResponseEntity
- 애플리케이션 예외 처리 실습
✔︎ GlobalExceptionAdvice의 기능 3가지 추가
handleBusinessLogicException()
ResponseEntity
를 이용해 처리handleHttpRequestMethodNotSupportedException()
@ResponseStatus
애너테이션을 사용해 처리@ResponseStatus(HttpStatus.METHOD_NOT_ALLOWED)
handleException()
@ResponseStatus
애너테이션을 사용해 처리@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
☞ 유형에 따라 다른 방법으로 예외를 처리할 수 있어서 헷갈릴 수도 있고, 어떻게 보면 해당 유형에 맞는 방법이 존재하기에 편리할 수도 있다. 해당 이론 학습을 공부하고, 페어와 함께 실습을 통해 과제를 해결해가도 이해가 되지 않는 부분들이 있었는데, 라이브 세션과 오늘 회고를 통해 다시 한 번 복습하면서 이제 어느 정도 정리가 되는 기분이다 :)
오늘 과제는 따로 예시라 해야하나..? 보기같은 게 없어서 페어와 함께 직접 코드를 입력해가며 알아내가야 했기에 어느 정도 난이도가 있었던 것 같다. 또한, 과제를 할 때는 유형에 따른 다른 방법이 있다는 걸 100% 이해하지 못해서 '왜 기능1에서는 이런 구조로 코드를 작성했는데, 기능2와 3에서는 다른 구조가 나오는 것 같은데..??' 하며 서로 찜찜함을 공유했다 ^^,, 그래도 혼자했으면 어려웠을 것 같은 과제가 서로 다른 사람이 서로의 생각을 나누며 해결해가니 많이 도움이 됐던 것 같다!
내일부터는 JDBC에 들어가면서 크루님께서 난이도가 좀 어려워질 거라 하셨기에 마음 단단히 먹고 더 화이팅해내가야겠다!
・ JDBC
・ Spring Data JDBC