gmelon
commented
5 months ago 책에 보면 과거에는 API의 예외를 (코드 레벨에서) 복구할 수 있는 가능성이 조금이라도 있다면 체크드 예외로 만들었고, 지금은 복구하지 못할 가능성이 조금이라도 있다면 언체크드예외로 만든다고 말합니다.
또, 과거에는 주로 싱글쓰레드 기반으로 사용자와 직접 상호작용하는 앱이 많았으므로 이러한 예외의 즉각적인 처리 및 복구가 중요했지만, 최근은 멀티쓰레드 기반의 웹 개발이 주류가 되면서 응답을 복구하지 않고 쓰레드가 종료되어도 상관없어졌다고 합니다. 오히려 빠르게 종료하고 오류 메시지를 친절하게 표시하는게 더 중요해졌다고 말이죠. 이러한 이유 때문에 최초에는 체크드로 설계되지 않았을까 (그리고 이제는 언체크드로 감싸서 사용하고) 생각합니다.
아래부터는 GPT의 답변인데, 내용이 괜찮은 것 같아서 요약해서 첨부했습니다.
SQLException이 코드 레벨에서 복구하기 어려운 경우가 많은 것은 사실입니다. 이는 주로 데이터베이스 작업 중 발생하는 다양한 문제들이 외부 시스템이나 환경 설정에 기인하기 때문입니다. 예를 들어, 네트워크 문제, 데이터베이스 서버의 장애, SQL 쿼리의 오류, 권한 문제 등이 있을 수 있습니다. 이런 경우들은 대부분 개발자가 직접 코드를 통해 즉각적으로 해결할 수 있는 문제들이 아니죠.
그럼에도 불구하고, SQLException을 Checked Exception으로 처리하는 이유는 여러 가지가 있습니다:
-
에러 로깅과 진단: 실시간으로 문제를 해결하지 못하더라도, 예외가 발생했을 때 적절한 로깅을 통해 문제를 기록하고 분석할 수 있는 기회를 제공합니다. 이는 시스템을 개선하거나 유사한 문제를 더 빠르게 진단하는 데 도움이 될 수 있습니다.
-
트랜잭션 관리: 데이터베이스 작업은 종종 트랜잭션의 일부로 수행됩니다. 예외 발생 시 현재 트랜잭션을 롤백하여 데이터의 일관성을 유지할 수 있습니다. 이는 복구 작업의 일환으로 볼 수 있습니다.
-
조건 분기 처리: 특정
SQLException의 오류 코드를 분석하여 예외의 원인에 따라 다른 조치를 취할 수 있습니다. 예를 들어, 일시적인 네트워크 문제 때문에 예외가 발생했다면, 재시도 로직을 구현할 수 있습니다. -
사용자 피드백: 발생한 예외를 사용자에게 보다 이해하기 쉬운 메시지로 변환하여 제공할 수 있습니다. 예를 들어, 데이터베이스 연결 실패는 사용자에게 "서비스에 일시적인 문제가 발생했습니다. 잠시 후 다시 시도해 주세요."라는 메시지로 안내할 수 있습니다.
현대의 많은 애플리케이션과 프레임워크는 SQLException 같은 Checked Exception을 런타임 예외로 변환하여 처리하는 방식을 채택하고 있습니다. 이러한 접근 방식은 개발자가 예외 처리 코드를 더 유연하게 관리할 수 있게 하면서도, 필요할 때 명시적으로 예외 처리를 할 수 있는 선택권을 제공합니다. 예를 들어, 스프링 프레임워크는 DataAccessException을 통해 데이터 액세스 중 발생하는 예외를 추상화하고 이를 런타임 예외로 처리하도록 함으로써, 개발자가 예외 처리 로직을 보다 쉽게 구성할 수 있도록 돕습니다.
책에서는 SQLException은 대부분 복구가 불가능하므로, 기계적인 throws 선언이 등장하도록 방치말고 가능한 빨리 언체크/런타임 예외로 전환해줘야 한다고 말합니다.
여기서 드는 의문이 처음부터 SQLException을 Unchecked로 만들어졌다면 이렇게 전환하지 않아도 될텐데 왜 Checked로 만들었는지 궁금합니다!