본격적인 뉴스피드 백엔드 개발이 시작되었다. 내가 맡은 게시글 CRUD부분을 구현하면서 발생한 오류 및 중요한점을 적어 나갈예정이다.
예외처리
게시글 CRUD 기능을 구현하면서 기능 로직자체를 구현하는것도 고민이였지만 가장 큰 고민은 어떻게 예외처리를 하는가 였다. 게시글의 전체목록 조회는 해당 페이지가 불러오면서 자동으로 이뤄질만큼 클라이언트로부터 예외가 발생할만한 요청이 아니기 때문에 큰 문제가 되진않았지만 특정 게시글 조회 생성 수정 삭제 의 경우 고려해야할 상황이 늘어나게된다. 각 상황에 해당하는 예외처리메서드의 개수 또한 늘어나게 되는건 당연지사이다.
위에는 Controller단, 아래는 Service단 이다
개인 프로젝트때는 기능 로직만 구현잘하면 된다는 잘못된 생각으로 위와 같이 예외종류가 다름에도 불구하고 하나로 일반화 하거나 잘못된 예외처리 사용법으로 코드의 가독성이 해침과 동시에 REST API를 지키지 못한 코드가 탄생하였다. 이번에는 설계 단계에서 부터 어떠한 오류가 나올지에 대해 생각하고 설계를 함과 동시에 알맞은 예외처리문을 사용하여 코드의 가독성과 REST API를 지키려고 노력한 코드가 됬다고 생각한다.
기존의 예외상황이 발생시 일괄되게 null처리 한 이유는 메서드의 반환타입에 대한 고민의 결과였다. 이번에 작성한 코드를 비교해보면 null처리한 부분을 BoardRpository에서 Optional<Board>로 초기화 하여 orElseThrow()메서드를 사용할수있게 하였고 람다식을 사용하여 Throw상황이 발생하면 해당 예외처리와 예외문구가 발생하게 하였다.
두개의 값을 비교시 틀릴경우 발생하는 예외상황의 경우 기존처럼 if문을 사용하되 해당 if문의 조건식이 만족하면 컨트롤러단으로 오류를 흘려보내 Controller에서 오류를 처리하도록 하였다.
해당 프로젝트의 컨트롤러단이다.
컨트롤러단에는 tru-catch문을 사용하여 서비스단에서 오류발생시 해당 예외처리된 메세지와 상태코드를 반환하도록 구현하였다.
원활하게 서버가 동작되기위해서는 개발자가 치밀하게 예측한 오류인 예외상황에 대한 처리가 중요하다고 생각되었다. 개인프로젝트때의 잘못된 생각을 고치고 앞으로 올바른 개발을 할수있도록 더욱 노력해야겠다는 생각이 들었다.
