[토비의 스프링] 4.1.3 중첩 예외의 장점?

[kjsu0209]

중첩 예외의 예시로 DuplicateUserIdException이 나오는데, 의미가 모호한 SQLException을 한 겹 감싸서 의미를 좀 더 명확하게 한다는 장점이 있다고 합니다.

이 부분에 있어서 중첩 예외가 유용하다고 생각 되지만 SQLException을 던질 때 중복된 Id 값입니다라는 오류 메시지를 같이 던져서 의미를 명확하게 하면 되지 않을까 의문이 듭니다.

+@
예를 들어 User, Order, Item이라는 테이블에 접근해서 insert를 수행하는 api를 개발한다면 unique 값 중복 에러를 어떻게 처리하면 좋을까요?
제가 생각한 방법은 DuplicateUniqueValueException을 하나 만들어서 에러가 발생할 경우 어느 테이블에서 발생했는지에 대한 것만 생성자 파라미터로 넘겨주는 것인데, 어차피 insert api를 호출하는 요청이 잘못 되었으니까 BadRequestException을 던질 수도 있겠죠,,,
어느 시점에서 exception의 의미를 명확하게 해 주어야 할지 생각하게 되네요 🤔

[taxol1203]

저도 이 부분이 헷갈려서 바로 위에 이슈를 남겼는데,
SQLException은 체크 예외이며, 이것을 catch로 잡아 봤자 복구 할 방법이 없으므로, 차라리 아이디 중복을 나타내는 예외인 DuplicatedUserIdException으로 포장하고 더 이상의 예외 처리를 하지 않겠다는 뜻으로 런타임 예외(언체크 예외)로 만드는 것이 아닐까 추측을 해봅니다. 👀

[daebalprime]

유저 아이디가 중첩되는 경우에는 회원가입 작업을 중단시키고 오류 메세지를 유저에게 띄운다거나 충돌이 나지 않도록 하는 등의 예외 처리를 해 주어야 할 것이고, 그렇게 하기 위해서는 catch를 할 때 어떤 예외를 잡아야 하는지에 대한 고민에서 예외 전환이 등장합니다.DuplicateUserIdException 대신 SQLException을 메세지와 함께 감싸서 던진다면, 실제 예외를 처리해야 할 객체에서 이게 DB가 터진건지, id가 중복인건지, 커넥션이 모자란건지... 하는 걸 다룰 수가 없기 떄문이 아닐까요? 메세지를 직접 파싱해서 예외처리에 쓰는건 진짜 넌센스한 일이 될 테구요.
의미의 명확은 개발자와 같은 사람에게만 해당하는 일이 아니라 try/catch로 예외를 잡는 프로그램의 입장도 함께 포함하는 개념인 것 같습니다.

+@
어떤 의미인진 모르겠지만 제가 이해한 내용은

1. 한 메서드에서 3개의 테이블에 insert를 수행한다.
2. 각 테이블에 해당하는 insert를 수행하는 메서드를 각각 하나씩 구현한다.
   둘 중 하나인 것 같은데, 2번의 경우는 굳이 예외에 테이블을 집어넣어야 할까라는 생각이 있고(메서드가 각 테이블에 insert하는 작업을 대표하니까...) 1번의 경우에는 잘못 짜여진 코드가 아닐까 합니다. 각각 분리하여 별개의 메서드로 구현하는 편이 옳다고 생각이됩니다. 굳이 저렇게 구현해서 예외처리의 복잡함을 늘릴 일인가...싶네요