[개발생각] 코틀린에서 Exception과 Transactional관계에 대해서

코틀린에서는 Checked Exception 개념이 존재하지 않는다.

 

그로인해 모든 Exception은 RuntimeException과 같이 동작하고,

그 가장 큰 수혜라고 하면, 함수간에 Exception을 주고받을 명세 throws Exception 같은 코드들이 없어지는 깔끔함일것이다.

 

처음에 이 개념을 알고, 좀 혼란스러웠던 경험이 있다.

 

바로 스프링에서 사용하는 @Transactional의 사용에서 였다.

 

java에서

@Transactional(rollbackOn = [Exception::class, Throwable::class])

이런식으로 정의해서,

Checked Exception인경우도 롤백이 되도록 설정을 하여, 많이 사용했다.

하지만, 코틀린에서는 Checked Exception개념이 존재하지 않고, 모두 Unchecked Exception개념으로 동작한다면,

저 옵션은 없어도 되는게 아닌가? 라는 생각이 문득들었다.

(스프링 트랜잭션은 기본적으로 Unchecked Exception일때만 롤백이 되니까)

 

상당히 합리적인 의심이라고 생각이 들었고,실제로 옵션을 제거하고, 트랜잭션 롤백 테스트를 해본결과,

Exception발생시, 롤백이 되지않았다.

Transactional 동작은 java에서와 동일하게 동작함을 알았다.

저 옵션이 존재해야한다는것은 테스트를 통해 입증이 됬지만, 왜 있어야하지 라는 생각이 계속 들었다.

(코틀린은 모두가 UnChecked Exception으로 동작하는뎅,,,,)

 

역시, 궁금하면...코드를 파보아야 겠지..

@Override
public boolean rollbackOn(Throwable ex) {
    return (ex instanceof RuntimeException || ex instanceof Error);
}

 

스프링 트랜잭션관련 코드를 찾았다..

코드를 보고 깨달았다.

 

트랜잭션은 스프링에서 코드로 관리하는 스코프이며, 코틀린에서의 Uncheck, Check Exception의 동작은 코틀린 컴파일러의 스코프라는것을...

결국 코틀린에서 컴파일러단에서 처리하는 룰은 별개이며,

스프링에서 트랜잭션을 처리하는 룰은 클래스의 타입을 보고 하는것이기 때문에 전혀 연관이 없다는 것을 알수있었다.

 

스프링 트랜잭션에서는 단순하게 클래스의 타입을 보고 롤백여부를 판단하기에,

코틀린같은 jvm언어에서 Exception을 어떻게 정의하고, java와 다르게 정의를 하고 컴파일을 하던, 영향이 없었던 것이다.

(트랜잭션에서는 클라스 타입만으로 판단을 하니까!!)

 

단순히 생각하면, 룰과 구현을 혼돈하고 실수를 할수있을것같다.

룰과 그 룰에서 사용하는 실제 클래스의 구현을 같은 개념으로 동작한다고 혼돈할수있다는것을 깨달았다.