데브원영

어떤 메서드에 대해 예외가 발생할 수 있다고 선언했다면, 그것은 API를 이용할 프로그래머에게 무언가를 알리려는 것이다. 무시하면 안된다. 아래와 같은 코드로 손쉽게 무시 할 수도 있다. 위와 같은 코드처럼 무시할 수도 있지만 매우 의심스럽고 가독성도 떨어지고 이유를 알기가 어렵다. catch블록안에 적절한 코드가 없다면 적어도 catch 블록 안에는 예외를 무시해도 괜찮은 이유라도 주석으로 남겨두기라도 해야만 한다. End of Document.

메서드를 올바르게 사용하려면, 메서드에서 던져지는 예외에 대한 설명이 문서에 있어야 한다. 따라서 문서화는 아주 중요하다.(당연한 이야기) 1. Javadoc @throws 태그를 사용해서 정확하게 밝히기2. 같은 이유로 동일한 예외를 던지는 메서드가 많으면 메서드마다 문서를 만들지말고, 예외에 대한 문서를 클래스의 문서화 주석(documentation comment)에 남기자. 단순하지만 명확한 결론 결론 : 메서드가 던질 가능성이 있는 모든 예외를 문서로 남기자

자바 플랫폼 라이블러리에는 대부분의 API가 필요로 하는 기본적인 unchecked exception들이 갖추어져 있다. 이미 있는 예외들은 재사용하면 아래와 같은 좋은 점이 있다. 1. 배우기 쉽고 사용하기 편리한 API를 만들 수 있다.2. 표준 예외를 사용한 API는 가독성이 높다.3. 예외 클래스 개수를 줄이면 프로그램의 메모리 요구량이 줄어들고, 클래스를 로딩하는 시간도 줄어든다.(확인 불가..) 아래는 가장 널리 재사용 되는 예외를 정리한 표이다. 예외 사용법 IllegalArgumentException null이 아닌 인자의 값이 잘못되었을 때 IllegalStateException 객체 상태가 메서드 호출을 처리하기에 적절치 않을 때 NullPointException null 값을 받으면 ..

아래와 같은 코드를 써서 반복구문(loop)를 돌리는 개발자는 없다.(없어야만 한다) 문제점이 뭐냐? 크게 3가지로 볼 수 있다.(라고 책에 나와있다.) 1. 예외는 예외적 상황을 위해 설계된 것이므로 JVM수준에서 보면 빠르게 만들 필요가 없다.2. try-catch 블록안의 코드는 최신JVM의 최적화 기법 중 일부분이 적용되지 않는다.3. array 내부의 중복 검사가 이루어지지 않는다. 그런데 위 내용에서 추가적으로 책에서 설명한 부분이 있다. "사실 최신 JVM에서 돌려보면 예외를 통해 구현한 순환문이 표준적 순환문 보다 훨씬 느리다. 필자의 컴퓨터에서는, 100개 원소를 갖는 배열일 때 두 배 이상 느렸다." 라는 글을 보고 직접 실험해보기로 하였다. 1. for loop 2. try-catch..