메서드와 생성자 대부분은 입력 매개변수의 값이 특정 조건을 만족하기를 바란다. 예를 들어 인덱스 값은 음수이면 안 되며, 객체 참조는 null이 아니어야 하는 식이다. 이런 제약은 반드시 문서화해야 하며, 메서드 몸체가 시작되기 전에 검사해야 한다. **“오류는 가능한 한 빨리 (발생한 곳에서) 잡아야 한다”**는 일반 원칙의 한 사례이기도 하다.

메서드 몸체가 실행되기 전에 매개변수를 확인한다면 잘못된 값이 넘어왔을 때 즉각적이고 깔끔한 방식으로 예외를 던질 수 있다. 매개변수 검사를 제대로 하지 못하면 몇 가지 문제가 생길 수 있다. 첫 번째, 메서드가 수행되는 중간에 모호한 예외를 던지며 실패할 수 있다. 더 나쁜 상황은 메서드가 잘 수행되지만 잘못된 결과를 반환할 때다. 한층 더 나쁜 상황은 메서드는 문제없이 수행됐지만, 어떤 객체를 이상한 상태로 만들어놓아서 미래의 알 수 없는 시점에 이 메서드와는 관련 없는 오류를 낼 수 있다. 다시 말해 매개변수 검사에 실패하면 실패 원자성을 어기는 결과를 낳을 수 있다.

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이면 m.signum( ) 호출 때 NullPointerException을 던진다. 그런데 “m이 null일 때 NullPointerException을 던진다”라는 말은 메서드 설명 어디에도 없다. 그 이유는 이 설명을 개별 메서드가 아닌 BigInteger 클래스 수준에서 기술했기 때문이다. 클래스 수준 주석은 그 클래스의 모든 public 메서드에 적용되므로 각 메서드에 일일이 기술하는 것보다 훨씬 깔끔한 방법이다. @Nullable이나 이와 비슷한 애너테이션을 사용해 특정 매개변수는 null이 될 수 있다고 알려줄 수도 있지만, 표준적인 방법은 아니다. 그리고 같은 목적으로 사용할 수 있는 애너테이션도 여러 가지다.

자바 7에 추가된 java.util.Objects.requireNonNull 메서드는 유연하고 사용하기도 편하니, 더 이상 null 검사를 수동으로 하지 않아도 된다. 원하는 예외 메시지도 지정할 수 있다. 또한 입력을 그대로 반환하므로 값을 사용하는 동시에 null 검사를 수행할 수 있다. 반환값은 그냥 무시하고 필요한 곳 어디든 null 검사 목적으로만 사용해도 된다.

this.strategy = Objects.requireNonNull(strategy, "전략");

자바 9에서는 Objects에 범위 검사 기능도 더해졌다. checkFromIndexSize, checkFromToIndex, checkIndex라는 메서드들인데, null 검사 메서드만큼 유연하지는 않다. 예외 메시지를 지정할 수 없고, 리스트와 배열 전용으로 설계됐다. 또한 닫힌 범위(양 끝단 값을 포함하는)는 다루지 못한다.

공개되지 않은 메서드라면 패키지 제작자가 메서드가 호출되는 상황을 통제할 수 있다. 따라서 오직 유효한 값만이 메서드에 넘겨지리라는 것을 제작자가 보증할 수 있고, 그렇게 해야 한다. 다시 말해 public이 아닌 메서드라면 단언문(assert)을 사용해 매개변수 유효성을 검증할 수 있다.

private static void sort(long a[], int offset, int length) {
	assert a != null;
	assert offset >= 0 && offset <= a.length;
	assert length >= 0 && length <= a.length - offset;

	// 계산 수행
}

여기서의 핵심은 이 단언문들은 자신이 단언한 조건이 무조건 참이라고 선언한다는 것이다. 이 메서드가 포함된 패키지를 클라이언트가 어떤 식으로 사용하든 상관없다. 단언문은 몇 가지 면에서 일반적인 유효성 검사와 다르다. 첫 번째, 실패하면 AssertionError를 던진다. 두 번째, 런타임에 아무런 효과도, 아무런 성능 저하도 없다(단, java를 실행할 때 명령줄에서 -ea 혹은 —enableassertions 플래그를 설정하면 런타임에 영향을 준다).

때로는 계산 과정에서 필요한 유효성 검사가 이뤄지지만 실패했을 때 잘못된 예외를 던지기도 한다. 달리 말하면, 계산 중 잘못된 매개변수 값을 사용해 발생한 예외와 API 문서에 던지기로 한 예외가 다를 수 있다는 뜻이다. 이런 경우에는 예외 번역 관용구를 사용하여 API 문서에 기재된 예외로 번역해줘야 한다.

메서드나 생성자를 작성할 때면 그 매개변수들에 어떤 제약이 있을지 생각해야 한다. 그 제약들을 문서화하고 메서드 코드 시작 부분에서 명시적으로 검사해야 한다. 이런 습관을 반드시 기르도록 하자. 그 노력은 유효성 검사가 실제 오류를 처음 걸러낼 때 충분히 보상받을 것이다.