아이니그마

이전까지는 try catch로 했었다 하지만 결제 시스템을 만들기 시작하면서 좀 더 좋은 예외처리가 필요했고 앞으로 try catch보다는 이 방법을 더 많이 사용할 거 같다 이전에도 본 방법이지만 귀찮아서 그리고 토이 프로젝트이니 그때그때 예외를 막았다 커스텀 예외 생성 RestControllerAdvice에 추가 이렇게 쓰면 지저분한 try catch도 줄어든다

항상 가지는 고민이 있었다 예를 들어 userDto dto= dao.findByEmail(email) 했을 때 잘못된 값이 와서 null 반환된다면? 물론 try catch로 묶어서 throw new 런타임 익셉션으로 던지면 되지만 제네릭을 사용해서 dto를 널을 검사하고 null이면 예외를 던지면 어떨까...? 라는 생각을 하고 구현해봤다! 새로운 클래스를 만들었다 제네릭을 이용해서 dto 받은 다음 null이라면 예외를 일으킨다! errorRestController 테스트 전화인증 로직에서 말도 안 되는 값을 넣어놨다 완료! 사실 제네릭 한번 써보고 싶었다 ㅋㅋㅋ

kim's cafe에이어 kim's shop을 만드는 도중 치명적인 오류가 있었다 무려 Transactional어노테이션이 먹히지 않았다.. 아예 작동하지 않았다 UPDATE문도 던지지 않고.. 근데 업데이트야 뭐 sql문을 던지면 되지만 제일 두려운 게 rollback이었다 어노테이션 덕에 rollback을 쉽게 알아서 해주는데 그걸 사용할 수 없게 된 거 같았다.. 결론 일단 해결했다 어노테이션 위치가 잘못되어있었다 흐름은 이렇다 프런트(3030)에서 요청->(8080)으로 전달 -> controller->confrimService->senPhone함수-> sendSms함수-> updateconfrim함수 이전에 난 updateconfrim에 어노테이션을 붙여 놓았다 즉 마지막에 SET이 이뤄지는 곳..

전체적으로 중간 소스 정리를 해보았다 재밌었다 이전에는 예외를 일부로 일으킨다고..? 굳이 이런생각이 있었는데 왜 그런지 어떤 부분에서 일으켜야 하는데 조금은 알거 같은 생각이 들었다 @Transactional에 대해서도 이해가 조금더 높아졌다 또 한 번 느꼈지만 처음부터 변 수명이 나형식을 잘 정해서 해야 편하다는 걸 다시 느꼈다 예를 들어 댓글 등록/수정에는 @Transactional만 붙여놨다 이유는 행동이 하나이다 댓글의 코멘트만 바뀌면 되게 해 놨기 때문이다 하지만 글 등록/수정 시에는 @Transactional(rollbackFor = {Exception.class}) 사용했다 이유는 사진 같은 파일도 받는 과정에서 예기치 못한 에러가발생한다 예를 들어 실수로 이미지가 아닌 다른 형식의 파일을..