19. [과제] 오라클 공식문서 - Unchecked Exceptions

Because the Java programming language does not require methods to catch or to specify unchecked exceptions (RuntimeException, Error, and their subclasses), programmers may be tempted to write code that throws only unchecked exceptions or to make all their exception subclasses inherit from RuntimeException. Both of these shortcuts allow programmers to write code without bothering with compiler errors and without bothering to specify or to catch any exceptions. Although this may seem convenient to the programmer, it sidesteps the intent of the catch or specify requirement and can cause problems for others using your classes.

(의역) 자바프로그래밍 언어는 메소드가 unchecked exception을 catch문으로 잡거나, 명시해줄 필요가 없습니다. 개발자들은 오직 unchecked exceptions만을 던지거나 모든 예외들이 RuntimeException에서 상속되도록 만들고 싶다는 유혹을 받을 지도 모릅니다. 이런 RuntimeException과 그 서브클래스들만 예외로 사용하면, 개발자는 IDE에서 빨간줄로 나오는 컴파일러 오류를 신경쓰지 않을 수 있고, 예외를 지정하거나 catch문으로 던지는등의 수고스러움 없이 개발을 할 수 있습니다. 비록 이러한 예외처리방식이 개발자들에게 편리해볼 수 있지만, 이렇게 만든 클래스를 사용하는 다른 사람들이 예외를 파악하거나 예외를 특정하는 것에 불편을 겪을 수 있습니다.

Why did the designers decide to force a method to specify all uncaught checked exceptions that can be thrown within its scope? Any Exception that can be thrown by a method is part of the method's public programming interface. Those who call a method must know about the exceptions that a method can throw so that they can decide what to do about them. These exceptions are as much a part of that method's programming interface as its parameters and return value.

왜 자바를 만든 설계자들은 checked exception이 쓰인 코드 범위 내에서, 이 예외를 처리하도록 강제하기로 결정했을까요? 메서드에 의해 던져지는 예외들은 메서드의 기초 인터페이스입니다. 메서드를 호출하는 사용자들은 그 메소드가 던질 수 있는 예외들에 대해 알고 있어야 합니다. 그래야 그들은 그 메서드를 가지고 어떻게 개발해야 할지 알 수 있습니다. 이런 예외들은 메서드의 파라미터나 리턴과 같이 기본적인 구성요소입니다.

The next question might be: "If it's so good to document a method's API, including the exceptions it can throw, why not specify runtime exceptions too?" Runtime exceptions represent problems that are the result of a programming problem, and as such, the API client code cannot reasonably be expected to recover from them or to handle them in any way. Such problems include arithmetic exceptions, such as dividing by zero; pointer exceptions, such as trying to access an object through a null reference; and indexing exceptions, such as attempting to access an array element through an index that is too large or too small.

아마 이런 의문을 가질지도 모릅니다. "메서드가 던질수 있는 예외들(checked exception)도 같이 선언하는게 좋다면,  runtime exception(unchecked exception)들도 선언하는게 어떨까요?" Runtime exception들은 프로그래밍 문제를 나타내므로, API를 사용하는 클라이언트 코드가 이 에러를 해결하거나, 처리하도록 코딩하는 것을 합리적으로 기대할 수 없습니다. (이 예외가 발생할 것을 알더라도 코딩으로 해결할 수가없다. 그냥 예외던지는게 끝이다.) 

 

 

런타임 예외는 프로그래밍 문제로 인한 문제를 나타내므로 API 클라이언트코드가 이들로부터 회복되거나 어떤 방식으로든 처리될 것으로 합리적으로 기대할 수 없습니다.

 

Runtime exceptions can occur anywhere in a program, and in a typical one they can be very numerous. Having to add runtime exceptions in every method declaration would reduce a program's clarity. Thus, the compiler does not require that you catch or specify runtime exceptions (although you can).

 

 

One case where it is common practice to throw a RuntimeException is when the user calls a method incorrectly. For example, a method can check if one of its arguments is incorrectly null. If an argument is null, the method might throw a NullPointerException, which is an unchecked exception.

 

 

Generally speaking, do not throw a RuntimeException or create a subclass of RuntimeException simply because you don't want to be bothered with specifying the exceptions your methods can throw.

 

 

Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.