프론트단으로 에러메시지 전달 질문드립니다.

Question

사이드 프로젝트를 여러 사람과 진행하고 있는데 다들 코드 구현 방식이 달라서 질문올려봅니다.프론트에게 예외 메시지를 전달하는 경우를 가정하겠습니다.서비스단에서 예외메시지와 함께 예외를 던지고 컨트롤러에서 클라이언트에게 상태코드만 전달한다.서비스단에서 예외메시지와 함께 예외를 던지고 컨트롤러에서 클라이언트에게 상태코드와 예외메시지를 전달한다.서비스단에서 예외메시지와 함께 예외를 던지고 컨트롤러에서 아무 처리도 하지 않는다.(로그에만 출력됨)다들 자신만의 방식으로 코드를 구현하고 있는데 어떤게 더 나은 선택인지 잘 모르겠습니다.제 생각에는 클라이언트에게 메세지를 전달해주는 2번의 경우가 더 나은 선택이라고 생각이 되는데..프로젝트 개발 진도가 더 나가기 전에 컨벤션을 정해서 진행하고 싶은 마음에 질문 올려봅니다!

코마상태 · Answer

저의 눈에는 2 번이 나아보이네요. 3번은 백엔드 단에서는 간단해서 좋겠지만, 프론트엔드에서 할 일이죽어 나가겠는데요. 1 번은 그나마 상태별로 처리는 분기처리 가능하니 그나마 나은데, 문제는 1번의 경우 동일한 400 Bad Request 예외이지만 발생한 원인은 다른 두 개 있다고 하면 어떻게 구분 하려는건가 싶네요.보니까 예외던지면 그걸 컨트롤러에서 캐치 후 응답 하시려는 것 같은데, 그냥 코드도 길어지고 중복 코드 많아지는 방식 보다는, 서비스단이나 도메인 층에서 예외 던지고, 전역 예외 처리 하나 만들어서 거기서 에러 응답 포맷 만들어서 던져주는게 더 좋지 않을까 라는 생각을 해보면서 물러가봅니다.

도니코니 · Answer

2번에 로그끼지 출력되게 하면 제일 좋은거 같네요.그럼 사용자에게 메세지가 보일거고 개발자는 리턴코드로 예외처리를 할 수 있겠죠? 이런건 윗분 말대로 공통 처리 로직을 넣으면 코드 중복 줄일 수 있겠네요

곰같은개발자 · Answer

1.서비스단에서 예외메시지와 함께 예외를 던지고 컨트롤러에서 클라이언트에게 상태코드만 전달한다. - 화면 쪽과 백서비스가 협업이 잘된다면 괜찬습니다. 대신 서비스단 개발자 분들은 코드 정의를 해서 공유해야 합니다. - 장단점이 있다면 서비스는 향후 코드정의 + 공통만 잘 개발 해놓으면 크게 신경 안써도 되고 화면쪽은 다국어나 특정문구 치환이 편합니다.2.서비스단에서 예외메시지와 함께 예외를 던지고 컨트롤러에서 클라이언트에게 상태코드와 예외메시지를 전달한다. - 서비스에서 예외코드+예외메시지를 다 처리하므로 화면쪽은 크게 할일이 없으며 업무 경계가 명확하게 됩니다. - 대신 서비스 측은 테스트배드시 해당 에러 질문을 많이 받게 되서 약간 후반에 스트레스 받을수 있습니다.3.서비스단에서 예외메시지와 함께 예외를 던지고 컨트롤러에서 아무 처리도 하지 않는다.(로그에만 출력됨) - 이부분은 개인적으로 반대입니다. - 3번은 어차피 1번과 2번에도 서비스 로그는 당연 기록 되야 하며, 별도의 로그저장이나 관리하는 포인트는 공통으로 들어가야 되지 않을까 생각이 되네요 - 보통 ELK 방식을 할 경우에는 이렇게 하는데 프로젝트 인원들이 해당 ELK를 이해를 하지 못할 경우 혼란이 예상됩니다.다국어가 포함되야 한다면 저는 1번 다국어가 없이 국내 서비스 한정이라면 빠른 개발을 위해서 2번을...꾸욱...(튀엇!)

Namho Cho · Answer

1번방식은 상태코드에 상당히 많은 의미부여가 필요해서 서로 피곤해집니다. 한쪽은 문제를 표현하기 위해서 상태코드를 선택하느라 고민하고 한쪽은 그 상태코드가 정확히 무슨 문제를 의미하는지 해석하느라 곤란하겠죠2번방식으로 뭐때문에 오류가 났는지 알려주는게 아무래도 일반적으로 더 좋죠.3번은 프론트단을 전혀 고려하지 않는 방향인거같네요. 결과적으로 프론트도 필요에 따라 오류에 따른 출력변화가 있어야하는데 서버가 무응답으로 일괄한다면 어떻게 처리할 방도가 없죠다만 늘 그렇듯 정답은 없습니다 약속만 있을뿐이죠

프론트단으로 에러메시지 전달 질문드립니다.

4개의 답변

기술 목록