아이템 49. 매개변수가 유효한지 검사하라. - ksw6169/effective-java GitHub Wiki

• 매개변수에 대한 제약(ex. 매개변수 A는 not null 이어야 한다.) 이 있다면 반드시 문서화해야 한다.
• 또한 이 제약은 메소드 몸체가 시작되기 전에 검사해야 한다. 메소드 몸체가 실행되기 전에 매개변수를 확인한다면 잘못된 값이 넘어왔을 때 즉각적이고 깔끔한 방식으로 예외를 던질 수 있기 때문이다.

매개변수의 유효성 검사를 제대로 하지 못하면 몇 가지 문제가 발생할 수 있다.

• 메소드가 수행되는 중간에 모호한 예외를 던질 수 있다.
• 메소드가 잘 수행되지만 잘못된 결과를 반환할 수 있다.
• 메소드는 문제없이 수행됐지만 객체의 상태를 이상하게 바꿔서 미래의 알 수 없는 시점에 이 메소드와는 관련 없는 오류를 발생시킬 수 있다. (실패 원자성을 어기는 결과를 낳는다.)

실패 원자성

호출한 메소드가 실패했을 때 객체의 상태가 메소드 호출 이전의 상태를 유지하는 성질을 말한다. 만약 메소드가 실패했는데 객체의 상태가 변경되었다면 이는 실패 원자성을 어긴 것이다.

• public, protected 메소드는 매개변수 값이 잘못됐을 때 던지는 예외를 문서화해야 한다. (@throws javadoc 태그를 사용하면 된다.)
• 또한 매개변수의 제약을 문서화했다면 그 제약을 어겼을 때 발생하는 예외도 함께 기술해야 한다.

/**
 * (현재 값 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()을 호출할 때 NPE를 던진다. 하지만 이를 문서화하지는 않았는데, 이유는 이 설명을 개별 메소드가 아닌 BigInteger 클래스 차원에서 기술했기 때문이다. 클래스 수준 주석은 그 클래스의 모든 public 메소드에 적용되므로 각 메소드에 일일이 기술하는 것보다 훨씬 깔끔한 방법이다.

자바 7에 추가된 Objects.requireNonNull 메소드는 유연하고 사용하기도 편하다. 또한 원하는 예외 메시지를 지정할 수 있고 입력을 그대로 반환하므로 값을 사용하는 동시에 null 검사를 수행할 수 있다. (혹은 반환값을 무시하고 필요한 곳 어디서든 순수한 null 검사 목적으로 사용해도 된다.)

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

자바 9 부터 Objects에 범위 검사 기능이 추가되었다. 추가된 메소드들은 Objects.requireNonNull() 만큼 유연하지는 않다. 또한 예외 메시지를 지정할 수 없고, 리스트와 배열 전용으로 설계됐다. 아래 3가지 메소드 모두 조건을 만족하지 않는 경우 IndexOutOfBoundsException 을 발생시킨다.

// 0 <= {fromIndex ~ fromIndex+size} <= length 범위인지 검사한다.
public static int checkFromIndexSize(int fromIndex, int size, int length);

// 0 <= {fromIndex ~ toIndex} <= length 범위인지 검사한다.
public static int checkFromToIndex(int fromIndex, int toIndex, int length);

// 0 <= {index} < length 범위인지 검사한다.
public static int checkIndex(int index, int length);

• 공개되지 않은 메소드라면 메소드가 호출되는 상황을 통제할 수 있으므로 이 상황에서는 assert 를 사용해 매개변수의 유효성 검사를 수행할 수 있다.
• 즉, 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 를 던진다.
• 런타임에 아무런 효과도, 아무런 성능 저하도 없다. (단, 명령줄에서 -ea 혹은 —enableassertions 플래그를 설정하면 런타임에 영향을 준다. 이 옵션을 설정하지 않으면 assert는 동작하지 않는다.)

private static void sort(long a[], int offset, int length) {
    assert a != null;  // a != null이 아니라면 AssertionError 발생
    assert offset >= 0 && offset <= a.length;
    assert length >= 0 && length <= a.length - offset;
    System.out.println("정상!");
}

public static void main(String[] args) {
    sort(null, 0, 0);
}

-ea 혹은 —enableassertions 플래그 설정

IntelliJ Run/Debug Configurations > VM options에 -ea를 입력한 후 실행하면 assert 문이 동작한다.

메소드가 직접 사용하지는 않으나 나중에 쓰기 위해 저장하는 매개변수는 특히 더 신경써서 검사해야 한다. 다음 코드에서 Objects.requireNonNull 을 통한 null 검사를 생략하면 클라이언트가 이 메소드의 호출 결과로 받은 List 객체를 사용할 때가 되어서야 비로소 NPE가 발생한다. 따라서 이 List를 어디서 가져왔는지 추적하기 어려워 디버깅이 상당히 어려워질 수 있다.

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

    return new AbstractList<>() {
        @Override
        public Integer get(int index) {
            return a[index];
        }

        @Override
        public Integer set(int index, Integer element) {
            int oldVal = a[index];
            a[index] = element;
            return oldVal;
        }

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

• 메소드 몸체 실행 전에 매개변수 유효성을 검사해야 한다는 규칙에도 예외는 있다. 유효성 검사 비용이 지나치게 높거나 실용적이지 않을 때, 혹은 계산 과정에서 암묵적으로 검사가 수행될 때다.
• 예를 들어 Collections.sort(List) 처럼 객체 리스트를 정렬하는 메소드에서 리스트 안의 객체들은 모두 상호 비교될 수 있어야 하며, 정렬 과정에서 이 비교가 이뤄진다. 만약 상호 비교될 수 없는 타입의 객체가 들어 있다면 그 객체와 비교할 때 ClassCastException 을 던질 것이다. 따라서 비교하기 앞서 리스트 안의 모든 객체가 상호 비교될 수 있는지 검사해봐야 별다른 실익이 없다.
• 하지만 암묵적 유효성 검사에 너무 의존했다가는 실패 원자성을 해칠 수 있으니 주의해야 한다.
• 때로는 계산 과정에서 필요한 유효성 검사가 이뤄지지만 실패했을 때 API 문서에서 던지기로 한 예외와 다른 예외를 던지기도 한다. 이 경우에는 예외 번역(exception translate) 관용구를 사용하여 API 문서에 기재된 예외로 번역해줘야 한다.

예외 번역(exception translate)

상위 계층에서 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꿔 던지는 것을 말한다.

try {
    ... // 저수준 추상화를 이용한다.
} catch (LowerLevelException e) {
    // 추상화 수준에 맞게 번역한다.
    throw new HigherLevelException(...);
}

이번 장의 내용을 매개변수에 제약을 두는게 좋다고 해석해서는 안된다. 사실은 그 반대로 메소드는 최대한 범용적으로 설계해야 한다. 메소드가 건네 받은 값으로 무언가 작업을 할 수 있다면 매개변수 제약은 적을수록 좋다.

• 메소드나 생성자를 작성할 때 매개변수들에 어떤 제약이 있을지 고려해야 한다.
• 만약 제약이 있다면 매개변수의 제약들을 문서화하고 메소드 시작 부분에서 명시적으로 검사해야 한다.

• Effective Java 3/E