메서드와 생성자에서 입력 매개변수의 값에 대한 제약은 반드시 문서화
해야 하며, 메서드 몸체가 시작되기 전에 검사
해야 한다.
이는 "오류는 가능한 한 빨리 (발생한 곳에서) 잡아야 한다"는 일반 원칙의 한 사례이기도 하다.
특히, 생성자 매개변수의 유효성 검사는 클래스 불변식을 어기는 객체가 만들어지지 않게 하는 데 꼭 필요하다. 생성자는 "나중에 쓰려고 저장하는 매개변수의 유효성을 검사하라"는 원칙의 특수한 사례다.
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);
...
}
자바 7에서 추가된 java.util.Objects.requireNonNull
메서드를 사용하면 더 이상 null 검사를 수동으로 하지 않아도 된다.
이 메서드는 유연하고 사용하기 편하다.
this.startegy = Objects.requireNonNull(strategy, "전략");
이 메서드들은 아주 유용하고 편하다.
그렇지만 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;
...
}
실패 원자성
을 해칠 수 있으니 주의!)📌 핵심 정리
메서드나 생성자를 작성할 때면 그 매개변수들에 어떤 제약이 있을지 생각해야 한다.
그 제약들을 문서화하고 메서드 코드 시작 부분에서 명시적으로 검사해야 한다.
이런 습관을 반드시 기르도록 하자.
그 노력은 유효성 검사가 실제 오류를 처음 걸러낼 때 충분히 보상받을 것이다.