qna 피드백 (미션-4)

이번에는 wheejuni가 피드백을 달아주셨다.

 

하나하나 맛봐보자.

 

나의 질문사항이었다.

내 이전의 생각은 예외를 다 다뤄줘야 한다는 생각이 있었다.

그래서 내부에 검증 메서드가 항상 따라다녔고, 예외상황에 할 행동이 같이 있었다.

 

근데 제인의 ExceptionHandler를 보고 나도 도입을 해보자, 하고 도입해 봤다.

확실히 코드가 깔끔해졌다. 예로 login시에 다른 password가 오면 일반적인 로직으로 보지 않고 예외를 터트리면 

뭐 거기서 끝이다. 따로 검증이나 예외시 행동을 처리하지 않고

ExceptionHandler에서 해당 예외를 잡아서 처리해 주면 끝.

 

본인 기준으로 너무 아름다운 코드들로 변해갔다.

근데 작성을 하면서 한 가지 걸린 점은 너무 exception을 남발한다는 것이다. 예외상황은 너무 많았고 그에 대응해 계속해서 예외를 던져댔다. 그래서 마음 한편이 불편해 질문을 달았었다.

 

답변을 보고 안심이 됐다. 해도 괜찮구나. 앞으로 다 예외 던져야지.

근데 간과한 것이 있다. 내 머릿속에는 커스텀 예외를 가능한 만들지 말고 있는 예외를 써라 라는 생각이 박혀 있었다.

내 생각으로는 이미 있는 예외들로 충분히 표현할 수 있다고 생각했었는데, 그렇지 않았나 보다.

 

리뷰어의 말씀대로 NPE도 던져댔는데, 만약 다른 곳에서 NPE가 터져도 내가 정의해 놓은 Handler가 잡아서 내 입맛에 맞게 처리했다. 디버깅이 힘들어질 것이다.

 

그래서 custonException을 정의해서 사용했다.

 

이 부분도 확실히 놓쳤었다. 밑의 구문은 service의 delete를 호출해서 id만 넘겨주고 삭제하는 로직이다.

작성할 때 생각은 delete는 삭제하는 책임만 가지고 있어야 한다는 것이다.

그래서 controller 단에서 검증을 거쳤다. 이의 문제는 select 문이 2번 나간다는 것이었고, controller의 역할이 더 늘어났다는 문제가 있었다.

또 생각해 보니 delete시 검증을 진행해야 한다는 생각도 들어서 delete 쪽으로 검증을 옮겼다.

service에 새로운 메서드를 정의해 검증을 정의하는 게 맞을까?

단일 책임원칙을 어디까지 정해야 하는지 어렵다.

 

이번에는 custonException에서 문제가 생겼다. 

하고자 했던 일은 update시 비밀번호가 다르면 id값을 exception으로 받아서 다시 updateForm을 띄워주려고 했다.

그래야 controller에서 예외 분기문이 이쁘게 떨어져 나갔기 때문이다.

근데 옳지 않은 방법이었다. 아니 좀 더 미래의 내가 디버깅하기 쉽게 글귀를 추가해 줘야 했다.

 

그래서 id값과 글귀를 섞어서 예외를 던지게 바꾸고 Handler에서는 split로 잘라서 사용하게 했다.

 

처음에는 동의하지 않았지만 미션 5를 진행하다 보니 return값이 필요해졌다. boolean이 필요해졌는데

굳이 바꾸지 않고 return true 해 줬다. 어차피 false가 나오기 전에 예외가 안쪽에서 터지기 때문이다.

optional은 어려웠다. 잘 쓰기가.

새로운 answer를 던져주면 안 되었으니 예외를 터트리는 게 맞았다.

근데 터트리는 예외가 문제였다. 

null일 때 NPE를 터트리면 나중에 null에 접근할 때 터지는 NPE와는 무엇이 다른가?

그래서 새로운 예외를 정의해서 넣어줬다.

 

 

정리

---

너무 customException을 아꼈다는 거다. 너무 아끼다 보니 혼란을 야기했고, 다른 exception도 같이 처리해버리는 문제가 발생할 수 있었다.

앞으로는 시기적절하게 예외를 만들어 사용해야겠다.