unchecked exceptions / runtime exception 을 조심히 써야 한다. / 쓰지 마라 /
Java의 Exception 과 RuntimException 의 차이
다음은 ref. 1, ref. 2의 글을 정리했다.
Java 에서 RuntimeException, Error 는 unchecked exception 들이다. [ref. 1]
Exception 은 compiler 가 check 한다. 하지만 RuntimeException 은 check 하지 않는다.(unchecked) 그래서 대체로 java 에서 exception 을 처리해야 하는 code를 넣지 않아도 compiler 가 error 를 보여주지 않는다. 물론 code 에서 RuntimeException 을 try...catch 로 잡아서 처리하는 것은 가능하다.(참고)
예를 들면, 아래와 같은 code
public static void read() throws FileNotFoundException {
FileReader file = new FileReader("C:\\myproj");
...
} checked Exception 은 programming interface 의 하나이다. 누군가 method 를 만들때 parameter, return 값을 정의하는 것처럼 exception 을 정의해서 이것이 어떻게 동작하는지, 어떻게 사용하는지를 알려준다. (me: 예전의 c code 등에서 return 값의 error code 가 어떤 의미를 갖는지 설명해주는 것과 같은 용도로 볼 수 있겠다.)
RuntimeException 같은 unchecked Exception 은 그럼 왜 필요한가? 이것은 어떤 error 가 발생했을 때 API client code 가 합리적으로 그것에 대해 회복할 수 없거나, 어쨌거나, 그것을 다룰 수 없을 때, 예를 들면, ‘0으로 나누기’, null referene 로 object 에 대한 접근을 시도하는 등의 pointer exception, 잘못된 index 에 접근하는 index exception 등. (me: programmer 가 예상치 못한 error 등에 사용되는 exception 이라 보면 될 것 같다.)
그런데 이 RuntimException 을 모든 method 에 사용하는 것은 프로그램의 clarity 를 낮춘다. (me: 즉, program code 를 봐서는 어디서 exception 이 발생하는지를 알 수 없다.) 그래서 compiler 가 check 할 수 없다. 그중에 어떤 것은 check 돼야 하는 것임에도 불구하고 말이다.
RuntimeException 을 throw 하는 일반적인 예는, method 를 잘못 올바르지
않게 호출할 때이다. argument 로 null 이 들어가는 경우, method 는
NullPointerException 라는 unchecked exception 을 던질
것이다.
일반적으로 말하면, 단순히 당신의 method 들이 어떤 Exception 을 throw
해야 하는지 정의해야 하는 것을 하기 싫어서,
RuntimeException 를 throw 하지 말라, 그리고
RuntimeException 의 subclass 를 만들지 마라.
최소한 맞춰야 할 점: - client 가 합리적으로 exception 으로부터 회복돼야 할 것으로 기대한다면, 이것은 checked exception 으로 만들라. - 만약, client 가 exception 으로부터 회복하기 위해 아무것도 할 수 없다면, 그것은 unchecked exception 으로 만들어라.
