📌 UncheckedException

• 확인되지 않은 실수 (개발자의 실수).
• 문법적으로 uncheck라 정해놓았기 때문에, 컴파일 시점에 예외를 catch 하는지 확인하지 않는다.
• spring에서는 default가 트랜잭션 Rollback 이 되는 것이다.
  → rollback여부 바꿀 수 있다.
  
• 관련 예외
  • RuntimeException - NullPointerException, IndexOutOfBoundException

📌 checkedException

• java문법에 의해서 check를 해야한다. 명시적으로 checked로 되어 있는 구문이다
• CheckedException 이 발생할 가능성이 있는 로직은 반드시 복구, 회피, 처리
  해줘야 한다.
• 컴파일 시점에서 예외에 대한 처리가 안되어있다면 with try/catch 컴파일 에러가 발생한다. 처리를 하지 않았다면 예외가 발생하는 메서드에서 throws 예약어를 활용해서 던져야 한다
• spring에서는 default가 트랜잭션 Rollback 이 안되게 되어있다. 즉,checked exception은 발생해도 트랜잭션이 commit 돼버리므로 주의해야한다 → rollback여부 바꿀 수 있다.
  
• 관련 예외
  • IOException, SQLException

📌놓치기 쉬운 지식

1. checkedException과 uncheckedException의 transaction rollback 여부는 사실 개발자가 수정가능하다!

spring에서는 사실 이렇게 runtimeException은 rollback되고, uncheckedException은 rollback 안되는 것으로 위에 사진에 나온것처럼 설명되어있다. 그러나, 우리가 주목해야 할 점은 default라는 점! 우리가 변경해줄 수 있다.
-> @Transactional(noRollbackFor = { ExceptionA.class, ExceptionB.class })
-> @Transactional(rollbackFor = Exception.class)
즉, rollbackFor과 noRollbackFor 설정을 사용하면 된다.

2. 코틀린에서의 CheckedException

코틀린은 자바와 달리 Checked Exception을 강제하지 않는다.또한, 원하는 경우에만 try-catch를 쓸 수 있다.
자바 경우, 예를 들어, IOException을 반드시 처리해야 하기 때문에 (checked exception이므로) catch 문에 추가하거나, 함수에 throws IOException을 표기해 줘야 하지만 코틀린은 하지 않아도 컴파일에 문제가 없다.
코틀린 공식 문서를 보면, 코틀린이 Checked Exception을 강제하지 않는 이유가 나와있다.

참고) https://kotlinlang.org/docs/exceptions.html#checked-exceptions
해당 문서에서는, Checked Exception은 매 코드마다 try-catch로 예외를 처리해야하고, 이는 결국 개발자의 생산성을 낮출 뿐 아니라, 가독성 면에서도 좋지 않다라고 써져있었다.
즉, checked exception을 try-catch로 처리한 후 catch 내에서 별도로 커스터마이징된 명확한 예외인 unchecked exception을 다시 넘겨줄 바에는 아예 checked exception을 사용하지 않는 것이 더 좋을 수 있는 것을 말하고 있는 것 같다.

3. Error vs Exception

1) Error : 프로세스 자체에 영향
→ JVM에 영향(JVM은 한 프로세스), 주로 JVM에서 발생시키기 때문에 애플리케이션 코드에서 잡아서는 안되며, 잡아서 대응할 수 있는 방법도 없다.
2) Exception: 한 쓰레드에만 영향