메서드와 생성자 대부분은 입력 매개변수의 값이 특정 조건을 만족하기를 바란다. 예를 들면 인덱스는 음수 값이 아니라던지, 객체는 null이 아니여야 한다. 이런 제약은 반드시 문서화해야 하며 메서드 몸체가 시작되기 전에 검사해야 한다.
매개변수는 메서드 몸체가 실행되기 전에 확인해야 한다.
메서드 몸체가 실행되기 전에 매개변수를 확인한다면 잘못된 값이 넘어왔을 때 즉각적이고 깔끔한 방식으로 예외를 던질 수 있다. 매개변수를 잘못 검사하면 다음과 같은 문제가 발생하기 때문에 꼭 메서드 몸체가 실행되기 전에 확인하자
- 메서드가 수행되는 중간에 모호한 예외를 던지며 실패할 수 있다.
- 메서드가 잘 수행되었지만 잘못된 결과를 반환할 수 있다.
- 메서드는 문제없이 수행됐지만, 어떤 객체를 이상한 상태로 만들어놓아서 미래의 알 수 없는 시점에 이 메서드와는 관련 없는 오류를 낼 수 있다.
public과 protected 메서드는 예외에 대해 문서화해야 한다.
public과 protected 메서드는 매개변수 값이 잘못됐을 때 던지는 예외를 문서화해야 한다.(@throws 자바독 태그를 사용하면 된다.)
/**
* (현재 값 mod m) 값을 반환한다. 이 메서드는
* 항상 음이 아닌 BigInteger를 반환한다는 점에서 remainder 메서드와 다르다.
*
* @param m 개수(양수여야 한다.)
* @return 현재 값 mod m
* @throws ArithmeticException m이 0보다 작거나 같으면 발생한다.
*/
public BigInteger mod(BigInteger m) {
if(m.signum() <= 0)
throw new ArithmeticException("계수(m)는 양수여야 합니다. " + m);
}이 메서드는 m이 null이면 NullPointerException을 던진다. 하지만 메서드 설명 어디에도 이런 부분이 명시되어 있지 않은데 그 이유는 이 설명은 BigInteger 클래스 수준에서 기술했기 때문이다. 클래스 수준 주석은 그 클래스의 모든 public 메서드에 적용되므로 각 메셔드에 일일이 기술하는 것보다 훨씬 깔끔한 방법이다.
java.util.Objects.requireNonNull의 등장으로 더 이상 null 검사를 수동으로 하지 않아도 된다.
this.strategy = Objects.requireNonNull(strategy, "전략");public이 아닌 메서드에서의 유효성 검증
public이 아닌 메서드라면 단언문(assert)를 사용해 매개변수 유효성을 검증할 수 있다.
private static void sort(long a[], int offset, int length) {
assert a != null;
assert offeset >= 0 && offset <= a.length;
}여기서 핵심은 이 단언문들은 자신이 단언한 조건이 무조건 참이라고 선언한다는 것이다. 단언문은 유효성 검사와 몇 가지 면에서 다르다.
- 실패하면 AssertionError를 던진다.
- 런타임에 아무런 효과도 아무런 성능 저하도 없다.
유효성 검사의 예외
유효성 검사 비용이 지나치게 높거나 실용적이지 않을 때, 혹은 계산 과정에서 암묵적으로 검사가 수행될 때는 예외가 될 수 있다. 예를 들어, Collections.sort(list)처럼 객체 리스트를 정렬하는 메서드를 생각해보자. 리스트 안의 객체들은 모두 상호 비교될 수 있어야 하며, 정렬 과정에서 이 비교가 이뤄진다. 만약 상호 비교될 수 없는 타입의 객체가 들어 있다면 그 객체와 비교할 때 ClassCastException을 던질 것이다.
정리
메서드나 생성자를 작성할 때면 그 매개변수들에 어떤 제약이 있을지 생각해야 한다. 그 제약들을 문서화하고 메서드 코드 시작 부분에서 명시적으로 검사하자.