프로그램과 에러처리에 대해 바라보는 2가지 관점이 있습니다.
Look Before You Leap(LBYB) 는 프로그램이 정상적으로 동작할 수 있는 precondition을 만족하고 있는지 로직 수행 이전에 체크하는 방식을 의미합니다. if문 등을 통해 precondition을 체크하며, 만약 잘못된 조건이라면 관리하는 Error Table에서 해당하는 에러를 찾아 반환합니다.
이러한 방식을 채택하기 위해서는 사전에 어떤 문제가 생길지에 대해서 다 알고 있어야합니다. 발생가능한 모든 에러를 규격화하고 정형화하는 것은 매우 어려운 일입니다.
또한 프로그램이 복잡해질 수록 수많은 if-else 문을 precondition 을 체크해야하는데 사용해야합니다. 이는 프로그램이 만들고 유지보수하는데 어렵게 만드는 요소입니다.
Easier to Ask Forgiveness Than Permission. 허락보다는 용서가 쉬운 법입니다. EAFP 는 사전에 모든 precondition을 체크하는 것이 아니라, 일단 프로그램의 로직을 수행하는 방식입니다.
일단 precondition이 만족되었다고 가정하고 프로그램의 로직을 수행하다가, 동작 도중 예외가 발생한다면 이를 처리할 수 있는 코드로 이동합니다.
이러한 깔쌈한 방식은 try와 except 구문을 통해 구현될 수 있습니다.
이 방식이 좋은 이유는 사전에 모든 발생가능한 에러를 치밀하게 고민할 필요가 없기 때문입니다. 이를 통해 좀 더 빠르게 개발할 수 있으며, 안정성 역시 보장할 수 있습니다.
Exception Handling은 EAFP의 관점에서 프로그램의 에러를 대비하는 방식입니다. 웹애플리케이션에서도 수 많은 예외가 발생 가능할 여지가 있습니다. 사용자의 요청을 처리할 Controller 부터, Service Layer, DAO Layer 혹은 더 하위의 Database Layer나 Network Layer에서도 예외는 발생할 수 있습니다. 스프링 개발자들은 이러한 다양한 곳에서 발생하는 예외를 어딘가에서는 catch 해주어 처리해야합니다. 예외를 처리하는 코드가 여러 레이어에 분산되어 있고 통일된 구조로 이루어져있지 않다면 프로그램의 cohesion이 떨어지고 유지보수하기 어려울 것입니다.
스프링에서는 Exception을 편리하게 처리할 수 있는 다양한 기능을 제공합니다. 이번 시간에는 개별 Controller 단위의 exception 을 처리하는 @ExceptionHandler 애노테이션과, 전체 컨트롤러 단위의 exception을 처리하는 @ControllerAdvice에 대해서 알아볼 것입니다.
백엔드 API의 반환값이 각각 다른 구조를 갖고 있다면, 응답을 받아 해석해야하는 프론트엔드 입장에서는 매 응답마다 다른 구조로 처리를 해줘할 것입니다. 이러한 문제를 해결하기 위해서 백엔드 서버의 응답은 통일된 구조를 가질 필요가 있습니다. 이러한 구조를 Response Template이라고 부릅니다.
이번 주차에는 Response Template 이 가져야 할 요소에 대해 알아보고 이를 구현하여 저희 프로젝트에 적용시켜 보겠습니다.