예외 래핑

3. 래핑 예외

확인된 예외는 이론적으로는 멋져 보였지만 실제로는 큰 좌절감을 안겨주었습니다.

프로젝트에 매우 인기 있는 메서드가 있다고 가정합니다. 프로그램의 수백 곳에서 호출됩니다. 그리고 새로운 체크 예외를 추가하기로 결정합니다. 그리고 이 확인된 예외는 정말 중요하고 너무 특별해서 main()잡히면 메서드만이 무엇을 해야할지 알 수 있습니다 .

즉, 매우 인기 있는 메서드를 호출하는 모든 메서드의 절 에 확인된 예외를 추가해야 합니다throws . throws해당 메서드를 호출하는 모든 메서드의 절 에서도 마찬가지입니다 . 그리고 그 메소드를 호출하는 메소드들.

결과적으로 throws프로젝트에 있는 메서드 중 절반의 절에 새로운 확인된 예외가 발생합니다. 물론 프로젝트가 테스트에 포함되어 있으며 이제 테스트가 컴파일되지 않습니다. 이제 테스트에서 throws 절도 편집해야 합니다.

그런 다음 모든 코드(수백 개의 파일의 모든 변경 사항)를 다른 프로그래머가 검토해야 합니다. 그리고 이 시점에서 우리는 왜 우리가 프로젝트에 그렇게 많은 피비린내 나는 변화를 가했는지 스스로에게 묻습니다. 확인된 예외 를 하나 추가하기 위해 작업 날짜 및 중단된 테스트가 모두 있습니까 ?

물론 상속과 메서드 재정의와 관련된 문제는 여전히 존재합니다. 확인된 예외 에서 발생하는 문제는 이점보다 훨씬 큽니다. 결론은 이제 그것을 좋아하는 사람이 거의 없고 사용하는 사람도 거의 없다는 것입니다.

그러나 이러한 확인된 예외를 포함하는 많은 코드(표준 Java 라이브러리 코드 포함)가 여전히 있습니다 . 그들에게 무엇을 할 것인가? 우리는 그것들을 무시할 수 없고 어떻게 처리해야 할지 모릅니다.

Java 프로그래머는 확인된 예외를 RuntimeException. 즉, 모든 확인된 예외를 포착한 다음 확인되지 않은 예외(예: RuntimeException)를 생성하고 대신 throw합니다. 이렇게 하면 다음과 같습니다.

try
{
   // Code where a checked exception might occur
}
catch(Exception exp)
{
   throw new RuntimeException(exp);
}

아주 예쁜 해결책은 아니지만 여기에는 범죄가 없습니다. 예외는 단순히 RuntimeException.

원하는 경우 여기에서 쉽게 검색할 수 있습니다. 예:

try
{
   // Code where we wrap the checked exception
   // in a RuntimeException
}
catch(RuntimeException e)
{
   Throwable cause = e.getCause();
   if (cause instanceof Exception)
   {
      Exception exp = (Exception) cause;
      // Exception handling code goes here
   }
}