비즈니스 로직 예외 처리? 질문 드립니다.

Question

안녕하세용.직장 업무로 서비스 레이어에서 비즈니스 로직을 작성하는 중인 초짜입니다.정상적인 상황이라면 전부 동작하긴 하는데,insert 문 전에 해당 값이 이미 db에 들어있는 지 조회하고없으면 insert 하는 등의 작업이 아예 안되어 있더라고용.제가 만든거 말고, 저 오기 전에 미리 만들어져 있던 것들이 대부분 그런 식이네용.물론 화면단에서 사용자에게 보여줄 때insert가 가능한 값만 보여주기는 합니다.근데 옛날에 혼자 공부할 때는 혹시 몰라서예외가 발생할 모든 케이스의 예외를 서비스 레이어에서 하나하나 컨트롤 했었는데,원래 다들 그냥 하시는 편이신가요?제가 개발 전문 회사는 아니여서개발 회사가 아니라서 이런 건지, 실제로 이런 경우가 많은 지 궁금합니다.

웹땔깜 · Answer

저는 페일 세이프티하게 만드는 게 맞다고 생각하는데(특히 클라이언트에서 변조 가능한 값 때문에 문제발생 가능한 경우) 제가 일하는 곳에서는 특별히 요구사항이 없는 한 일차적으로 체크가 되어있으면 개발자 재량이란 식으로 얘기하는 경우가 많더라구요...데이터 구조상 유니크한 값이라면 뭔가 공통적으로 처리되는 중복 예외처리가 프레임워크 레벨에서 되어있을지도 모르겠네요.

코딩하는 두루미 · Answer

테이블 Key값 확인도 해보셨나요? 명시적으로 중복체크 하지 않고 insert시 오류 발생하도록 설계되었을 수도 있지요

장독깨기 · Answer

PK, 유니크 키에 중복이 발생한다는건 데이터가 정상적인 경로로 들어온게 아닐거잖아요.그니까, 그냥 오류를 발생시키면 충분한데요,굳이 한번 더 SELECT 해서 중복을 확인할 필요까지는 없어 보입니다.전 보통은 이렇게 합니다. 상황에 따라 select 해서 미리 확인 할 경우도 있을 겁니다.

wharup · Answer

한 사람이 풀 스택으로 프론트/백을 담당하는 경우에는 일일히 체크하지 않는 경우도 많습니다.DB단에 중복 데이터가 들어가는 건 막혀있으니 정합성에 문제가 생기지는 않는 상황이니까요.값을 검증해서 더 정확한 오류 정보를 전달하면 사용자 문구도 명확해질 수 있고 담당자에게 증상을 리포팅할 때도 더 좋긴합니다만.. 혼자라면 백엔드 코드 보면서 어렵지 않게 원인 파악을 할 수 있으니까 안하더라도 큰 차이가 없게 느껴지는 거죠.반면에 서버 기능을 다른 팀이나 회사에서 호출하는 경우에는 가능한 세세히 검증해서 원인을 정확하게 전달해주는 게 좋습니다. 문의하거나 회의가 줄어드니 서로 좋고, 또 잘 모르는 사람이 엄한 실수하는 것도 막을 수 있습니다.저는 항상 하려고 합니다만.. 실용적이지 않은 경우가 있으니까요.

비즈니스 로직 예외 처리? 질문 드립니다.

4개의 답변

기술 목록