@Transactional에 대한 정리[번외] - RuntimeException와 Errorcode

애플리케이션을 개발할때  CustomException을 제작해서 따로 ErrorCode 정의 후 Exception을 떤져준다.

@Transactional을 떤져서  rollback을 의도한다.

 

그럼 Exception과 어떻게 구성할지 조금 더 확인해보자

 

흔히 아는 UncheckedException(RuntimeException)과 CheckedException이 존재한다.

 

둘의 차이점은?

 

나의 본 목적은 CustomException을 제작하여 나의 Exception을 떤지면서 rollback을 진행하고 싶다. 그러면 우선 내가 만드는 CustomExcpetion은 RuntimeExcpetion을 extends하자

 

그럼 요기서 잠깐  CheckedException은 왜 롤백을 진행하지 않는가?

기본적으로  checked exception은 복구가 가능한 매커니즘을 가지고 있다. 하지만 주의점은 복구 가능한 매커니즘을 가지고 있을뿐 전략은 가지고 있디 않는 경우가 많다.

 

예시로

유니크 값으로 존재하는 값에 대해서 중복으로인해  SQLException이 발생하는 경우 어떤 복구 전략을 가질 수 있을지?

1. 사용자가 입력한 이메일과 난수를 조합해서 DB에 insert를 진행하는것이 가능하다.

2. RunTimeException을 강제로 발생시켜서 사용자에게 재입력을 유도하는 방식도 가능하다.

 

이 상황에서 우리는 보통 2번을 전략을 가져간다.

 

해당 상황에서 제일 중요한 부분은 Exception이 발생하는 경우 이를 명확하게 어떤 예외  Exception이 발생했는지에 대한 정보를 전달하는게 바람직하다. 그래서 우리는  CustomException을 제작하고 애플리케이션안의  Error code로 어떤 상황에서 error가 발생했는지  표기한다. 

 

우리는 CheckedException이 발생하더라도 구체적으로 정의한  UncheckedException을 발생시켜서 정확한  error을 반환하고 해당 로직의 흐름을 끊어야 한다.

 

 

현재 진행하고 있는  Exception은 이정도이다.

 

최근에 Exception에 대한 글을 하나 확인해서 링크를 남겨둔다.

https://jojoldu.tistory.com/734

좋은 예외(Exception) 처리

어떤 Exception인지에 대해서 이름만으로 확인하는 방식을 말씀해주신다.

코드의 가독성과 디버그의 단계에서 많은 시간을 아낄 수 있다는 부분은 매우 찬성인데

한가지 궁금증이라면 이렇게 각각 선언하면...  class가 너무 많아지는 상황이 발생하는게 아닌가 하는 의문이 남기는 한다.

 

앞으로 개발하면서 어떻게 진행하는게 더 좋은지는 알아가봐야겠다.