@Transactional이 기본적으로 uncheckedException
즉 RuntimeException이 일어날 경우에만 에러 잡아서 rollback 시키는 것은 검색을 통해 알았다.- 하지만 Kotlin은 uncheckedException과 checkedException을 구분하지 않는다고 한다.
여기서 궁금증이,
기존에 unCheckedException랑 checkedException이 일어났을 경우 모두를 롤백 시키기 위해서 @Transactional(rollbackFor = [Exception::class]로 했는데, unCheckedException를 checkedException를 구분하지 않는데 @Transactional 은 unCheckedException만 잡아낸다면... 어떻게해야하지? 멘붕왔다.
1. Transactional의 범위를 어떻게 가져갈 것인지
2. unCheckedException이랑 checkedException를 구분하지 않는다면 이전의 checkedException는 뭐로 분류되는건지..?
결국 chatgpt한테 물어봤다.
- kotlin에서 checked exception이랑 unchecked exception을 구분하지 않는 다는 말 뜻을 알려줘
-
Kotlin은 Java와 달리 "checked exception"과 "unchecked exception"을 엄격하게 구분하지 않습니다. Java에서는 컴파일러가 checked exception을 감지하고 예외를 처리하도록 강제하지만, Kotlin에서는 그렇지 않습니다.
-
Kotlin은 예외 처리에 대한 명시적인 선언을 갖고 있지만, 이는 예외가 checked인지 unchecked인지를 나타내지 않습니다. Kotlin에서는 throws 키워드를 사용하여 함수가 예외를 던질 수 있음을 선언할 수 있습니다. 하지만, 이는 예외가 checked인지 unchecked인지를 구분하지 않고, 모든 종류의 예외를 나타냅니다.
- Java에서는 컴파일러가 checked exception을 감지하고 예외를 처리하도록 강제한다고 했는데 어떻게 하는건지 알려줘
-
Java에서처럼 Kotlin에서는 메소드 시그니처에 checked exception을 선언하는 것이 없습니다. 따라서 Kotlin에서는 예외를 처리할 때 try, catch 블록을 사용하고, 예외를 던질 때는 throw 키워드를 사용하면 됩니다.
-
Java에서는 컴파일러가 checked exception을 감지하고 예외를 처리하도록 강제하는데, 이는 예외를 선언하거나 처리하는 것이 명시적으로 필요하다는 것을 의미합니다. Checked exception은 RuntimeException을 상속하지 않는 예외 클래스로, 반드시 예외 처리를 해주어야 합니다.
- 그러면 java에서 throws로 checkedException을 명시해주지 않아도, 컴파일러가 checkedException이 발생한다는 것을 알아챌 수 있는 방법이 있는거야?
-
Java에서 throws를 사용하여 checked exception을 명시하는 것은 개발자가 메소드나 생성자에서 어떤 예외가 발생할 수 있는지 명시적으로 선언하는 방법 중 하나입니다. 그러나 Java 컴파일러는 checked exception이 발생한다는 것을 명시적으로 선언하지 않아도 해당 예외를 감지할 수 있습니다.
-
컴파일러는 메소드나 생성자에서 호출되는 다른 메소드나 생성자가 던지는 checked exception을 분석하고, 그 예외를 처리하지 않은 경우 컴파일 오류를 발생시킵니다. 이는 checked exception이 발생할 수 있는 부분에서 예외를 처리하지 않으면 컴파일 오류가 발생한다는 것을 의미합니다.
- checked exception이 일어날 수 있는 코드라는 것을 개발자가 어떻게 알 수 있어?
- 그렇다면 kotlin이 checked exception과 unchecked exception를 구분하지 않는다는 것은 checked exception을 꼭 throws로 예외처리를 해줄 필요가 없다는거야?
-
맞습니다. Kotlin에서는 checked exception과 unchecked exception을 엄격하게 구분하지 않습니다. Java에서처럼 메소드 시그니처에 throws를 사용하여 checked exception을 선언할 필요가 없습니다. Kotlin에서는 모든 예외가 unchecked exception으로 취급되며, 개발자는 명시적으로 예외를 선언하거나 처리하지 않아도 됩니다.
-
Kotlin에서 예외를 던지고 처리하는 방법은 Java와 유사하지만, throws 절을 사용하지 않습니다. 함수에서 예외를 던질 수 있는 경우에는 함수 시그니처에 명시하지 않고, 예외를 처리할 때는 try-catch 블록을 사용합니다.
- 그렇다면 @Transactional 은 runtimeException인 즉 unchecked exception만을 rollback시킨다고 했는데, kotlin에서는 checked exception와 unchecked exception을 구분하지 않더라도 unchecked exception을 rollback 시키는거야?
- Kotlin에서는 예외 처리 방식이 Java와 다르지만, Spring Framework의 @Transactional 어노테이션은 여전히 예외 처리에 영향을 미칩니다. Kotlin에서도 특정 메소드에 @Transactional 어노테이션을 사용할 경우, 해당 메소드에서 발생한 unchecked exception은 롤백의 대상이 될 것입니다.
- 그러면 @Transactional(rollbackFor = [Exception::class]) 로 checked exception까지 예외처리를 해주는게 나을까 아니면 기존 @Transactional 만 이용해서 unchecked exception 만 예외처리해주는게 좋을지 알려줘
-
@Transactional 어노테이션을 어떻게 사용할지는 상황과 요구사항에 따라 다릅니다. 여러 가지 상황에서 어떤 방식이 더 나은지 판단하는 것은 주관적이고, 프로젝트의 특정 요구에 따라 다를 수 있습니다. 아래는 각 접근 방식에 대한 고려사항입니다:
-
기본적인 @Transactional 사용:
장점: 코드가 간결하며, 롤백의 대상이 되는 예외를 명시적으로 선언하지 않아도 됩니다.
단점: checked exception이 발생할 때 롤백을 하지 않기 때문에 특정 예외에 대한 롤백이 필요한 경우, 롤백 로직을 추가해야 합니다. -
@Transactional(rollbackFor = [Exception::class]) 사용:
장점: checked exception에 대해서도 롤백이 수행되므로, 특정 예외에 대한 롤백 로직이 필요한 경우에 유용합니다.
단점: 모든 checked exception에 대해서 롤백을 수행하므로 예외 처리의 세부적인 제어가 어려울 수 있습니다. -
어떤 방식이 더 나은지는 프로젝트의 특성과 개발자의 선호도에 따라 다를 수 있습니다. 예를 들어, 특정 상황에서는 checked exception에 대한 롤백이 필요한 경우가 있을 수 있습니다. 하지만 이는 프로젝트의 특정 요구사항 및 예외 처리 전략에 따라 달라집니다. 따라서 어떤 방식을 선택할지는 프로젝트의 요구사항과 개발자의 기호에 따라 결정하면 됩니다.
- checked exception이 주로 일어나는 상황에 대해 알려줘
-
hecked exception은 주로 프로그램이 실행 중에 발생할 수 있는 외부적인 문제를 나타냅니다. Java에서는 이러한 예외들은 RuntimeException 클래스를 상속하지 않습니다.
-
다음은 몇 가지 checked exception과 그에 따른 상황들의 예시입니다:
- IOException: 파일 또는 네트워크와 관련된 입출력 작업 중에 발생합니다.
- SQLException: 데이터베이스와 상호작용할 때 발생할 수 있는 예외입니다.
- ClassNotFoundException: 클래스를 동적으로 로드할 때 해당 클래스를 찾지 못하면 발생합니다.
- InterruptedException: 스레드가 sleep, wait 등에서 대기 중이거나 중단되었을 때 발생합니다.
- ParseException: 문자열을 파싱하는 도중에 발생하는 예외로, 주로 날짜나 숫자 등을 파싱할 때 사용됩니다.
결론: rollback 으로 Exception 으로 잡고, runCatching내부에서 떨어질 에러를 미리 예측해서 controller에서 예외 잡아서 처리하자.
