Home [Backend] service, controller 어디서 예외처리 할까
Post
Cancel

[Backend] service, controller 어디서 예외처리 할까

참고 https://roadmap.sh/backend

예외 처리의 위치는 애플리케이션의 아키텍처와 설계 원칙에 따라 달라질 수 있습니다. 그러나 일반적으로 서비스(Service)와 컨트롤러(Controller) 레이어에서 예외 처리를 하는 데 있어 각각의 역할과 책임을 고려하는 것이 중요합니다.

서비스 레이어에서 예외 처리하기 비즈니스 로직 관련 예외: 서비스 레이어는 비즈니스 로직을 처리하는 곳입니다. 여기서 발생하는 예외는 주로 비즈니스 규칙의 위반, 데이터 무결성 문제, 또는 내부 로직의 오류와 관련이 있습니다. 재사용성: 서비스 레이어에서 예외를 처리하면, 해당 서비스가 여러 컨트롤러에서 재사용될 때 예외 처리 로직도 함께 재사용됩니다. 세부적인 예외 처리: 서비스 레이어에서는 더 세부적인 예외 처리가 가능합니다. 예를 들어, 다양한 종류의 예외를 구분하여 처리할 수 있습니다. 컨트롤러 레이어에서 예외 처리하기 사용자 인터페이스 관련 예외: 컨트롤러 레이어는 사용자 인터페이스와 관련된 예외를 처리하는 데 적합합니다. 예를 들어, HTTP 요청과 관련된 예외 처리(잘못된 요청, 권한 없음 등)는 컨트롤러에서 처리하는 것이 좋습니다. 통일된 에러 응답 형식: API를 제공하는 애플리케이션의 경우, 컨트롤러 레이어에서 예외를 처리하면 모든 API 응답에 대해 일관된 에러 응답 형식을 제공할 수 있습니다. 최선의 접근 방식 최선의 접근 방식은 두 레이어 모두에서 예외 처리를 하는 것입니다. 서비스 레이어에서는 비즈니스 로직과 관련된 예외를 처리하고, 컨트롤러 레이어에서는 이러한 예외를 받아 사용자에게 적절한 응답을 반환하는 방식으로 처리합니다. 이렇게 함으로써 로직의 복잡성을 줄이고, 코드의 가독성과 유지보수성을 높일 수 있습니다.

예를 들어, 서비스 레이어에서 발생한 ItemNotFoundException 같은 예외는 컨트롤러 레이어에서 적절한 HTTP 상태 코드(예: 404 Not Found)와 함께 클라이언트에 반환될 수 있습니다. 이렇게 하면 예외 처리 로직이 각 레이어의 책임과 잘 맞게 구성됩니다.

This post is licensed under CC BY 4.0 by the author.

[Backend] 시작하며 앞으로 공부할 것 정리

Redis 관련 배열 혹은 객체 어느 것이 더 좋을까...