• 카테고리

    질문 & 답변
  • 세부 분야

    백엔드

  • 해결 여부

    해결됨

Checked, Unchecked 예외 변환 질문드립니다.

24.01.18 23:09 작성 24.01.19 21:02 수정 조회수 146

0

안녕하세요. 복습 도중 개념적으로 혼동이 와서 질문드립니다.

  • Checked Exception - 체크를 하라고 만든 예외

  • Unchecked Exception(Runtime Exception) - 체크를 하지 말라고 만든 예외

예를 들어서 NullPointerException 같은 경우, 개발자가 예외를 잡아서 처리하지 않습니다.

런타임 예외는 원래 처리하지 않기 때문에 당연하다고 생각합니다.

그런데 체크를 하라고 만든 예외를 체크를 하지 말라고 만든 예외로 변환을 하는 것이 개념적으로 이해가 잘 가지 않습니다.

Checked 예외를 Unchecked 예외로 변환함으로써

Unchecked는 체크를 하는게 아닌데, 마치 Checked 처럼 핸들링 하는 느낌이 듭니다.

물론 강의에서 설명해 주신 변환을 함으로써의 이점은 이해가 잘 갑니다!

  • throws SQLExceptionthrows JPAException

  • 반복적인 throws 을 변경하지 않아도 되고, 특정 기술에 의존하지 않아도 됨

다만, 이는 커스텀 Checked 예외를 사용해도 해결할 수 있다고 생각합니다.

public class MyCustomCheckedException extends Exception { ... }
  • Checked 예외를 커스텀 Checked 예외로 변환

     

  • 이 경우에는 반복적인 throws 작성은 피할 수 없긴 합니다.

코틀린 등의 언어에서 이런 개념적 혼동을 막기 위해 Checked/Unchecked를 나누지 않는 것인지..

제가 무언가 잘못 이해하고 있는것이 있을까요?

답변 1

답변을 작성해보세요.

1

안녕하세요. Mpels님

이 경우에도 반복적인 throws를 피할 수 없습니다.

이렇게 되면 커스텀 Checked 예외라고 하더라도 모든 레이어에서 해당 커스텀 Checked 예외에 의존해야 하는 문제가 있습니다.

사실 Checked의 개념적인 문제보다 실질적인 문제는 개발자가 다루고 싶어하지 않는 예외도 몽땅 다 잡거나 던져야 하는 것인데, 이게 적절한 수준이면 관리가 될 수 있는데 세상의 모든 라이브러리에서 이렇게 체크 예외를 던지면 해당 라이브러리들을 사용하는 개발자가 잘 알지도 못하는 예외를 다 잡아야 하는 문제들이 발생합니다. 결국 체크 예외는 좋은 의도로 시작했지만, 지금과 같은 복잡한 애플리케이션을 개발할 때 실용성이 떨어지게 된 것이지요.

제가 옛날 사람이라 체크 예외의 지옥을 맛본 경험이 많아서 ㅋㅋㅋㅋㅋㅋ

참고로 이런 문제들 때문에 최근 라이브러리 대부분은 런타임 예외를 던집니다.

감사합니다.

Mpels님의 프로필

Mpels

질문자

2024.01.19

빠른 답변 감사드립니다!