Item49 - 매개변수가 유효한지 검사하라

메서드와 생성자 대부분은 입력 매개변수의 값이 특정 조건을 만족하기를 바란다.

ex) 인덱스 값은 음수 x, 객체 참조는 null값 x 등등

 

이런 제약은 반드시 문서화해야 하며 메서드 몸체가 시작되거 전에 검사해야한다. 메서드 몸체가 실행되기 전에 매개변수를 확인한다면 잘몯된 값이 너멍왔을 때 즉각적이고 깔끔한 방식으로 예외를 던질 수 있다.

 

public, protected 메서든ㄴ 매개변수 값이 잘못됐을 때 던지는 예외를 문서화해야한다. 보통은 IllegalArgumentException, IndexOutOfBoundsException, NullPointerException 중 하나가 될 것이다. 매개변수의 제약을 문서화한다면 그 제약을 어겼을 때 발생하는 예외도 함께 기술해야 한다. 이런 간단한 방법으로 API 사용자가 제약을 지킬 가능성을 크게 높일 수 있다.

 

ex)

/**
 * Returns a BigInteger whose value is {@code (this mod m}).  This method
 * differs from {@code remainder} in that it always returns a
 * <i>non-negative</i> BigInteger.
 *
 * @param  m the modulus.
 * @return {@code this mod m}
 * @throws ArithmeticException {@code m} &le; 0
 * @see    #remainder
 */
public BigInteger mod(BigInteger m) {
    if (m.signum <= 0)
        throw new ArithmeticException("BigInteger: modulus not positive");

    BigInteger result = this.remainder(m);
    return (result.signum >= 0 ? result : result.add(m));
}

 

이 메서드는 m이 null이면 m.signum() 호출 때 NullPointerException을 던진다. 이 설명은 메서드에 있지 않고 클래스 레벨로 주석이 달려 있다.

* <p>All methods and constructors in this class throw
* {@code NullPointerException} when passed
* a null object reference for any input parameter.

 

자바 7에 추가된 java.util.Objects.requireNonNull 메서드는 유연하고 사용하기도 편하니, 더 이상 null 검사를 수동으로 하지 않아도 된다.

public static void main(String[] args) {
    requireNonNullMethod(null);
}

public static void requireNonNullMethod(String string) {
    Objects.requireNonNull(string);
    String s = string;
}

 

공개되지 않은 메서드라면 패키지 제작자 스스로 메서드가 호출되는 상황을 통제할 수 있다. 따라서 오직 유효한 값만이 메서드에 넘겨지리라는 것을 보증할 수 있고, 그렇게 해야 한다.

public static void main(String[] args) {
    requireNonNullMethod(null);
}

private static void requireNonNullMethod(String string) {
    assert string != null;
    String s = string;
}

 

 

여기서의 핵심은 이 단언문들은 자신이 단언한 조건이 무조건 참이라고 선언하는 것이다. 단언문은 몇 가지 면에서 일반적인 유효성 검사와 다르다.

 

첫 번째, 실패하면 AssertionError를 던진다.

두 번째, 런타임에 아무런 효과도, 아무런 성능 저하도 없다.

 

메서드가 직접 사용하지는 않으나 나중에 쓰기 위해 저장하는 매개변수는 특히 더 신경 써서 검사해야 한다.

static List<Integer> intArrayAsList(int[] a) {
    Objects.requireNonNull(a);

    // 다이아몬드 연산자를 이렇게 사용하는 건 자바 9부터 가능하다.
    // 더 낮은 버전을 사용한다면 <Integer>로 수정하자.
    return new AbstractList<>() {
        @Override public Integer get(int i) {
            return a[i];  // 오토박싱(아이템 6)
        }

        @Override public Integer set(int i, Integer val) {
            int oldVal = a[i];
            a[i] = val;     // 오토언박싱
            return oldVal;  // 오토박싱
        }

        @Override public int size() {
            return a.length;
        }
    };
}

 

 

이 메서드는 null 검사를 수행하고 만약 클라이언트가 null을 건네면 NullPointerException을 던진다. 만약 이 검사를 생략했다면 새로 생성한 List 인스턴스를 반환하는데, 클라이언트가 돌려받은 LIst를 사용하려 할 때 비로소 NullPointerException이 발생한다. 이때가 되면 이 List를 어디서 가져왔는지 추적하기 어려워질 수 있다.

 

생성자는 "나중에 쓰려고 저장하는 매개변수의 유효성을 검사하라" 는 원칙의 특수한 사례다. 생성자 매개변수의 유효성 검사는 클래스 불변식을 어기는 객체가 만들어지지 않게 하는 데 꼭 필요하다.

 

메서드 몸체 실행 전에 매개변수 유효성을 검사해야 한다는 규칙에도 예외가 있다. 유효성 검사 비용이 지나치게 높거나 실용적이지 않을 때, 혹은 계산 과정에서 암묵적으로 수행될 때다.

 

Collections.sort(list)처럼 객체 리스트를 정렬하는 메서드를 생각해보자.

리스트 안의 객체들은 모두 상호 비교가 가능해야 하고 정렬 과정에서 비교가 이뤄진다. 만약 상호 비교될 수 없는 타입의 객체가 들어있다면 그 객체와 비교할 때 ClassCastException을 던질 것이다. 따라서 비교하기 앞서 리스트 안의 모든 객체가 상호 비교 가능한지 검사해봐야 실익이 없다.