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

메서드와 생성자 대부분은 입력 매개변수의 값이 특정 조건을 만족하기를 바란다. 예컨대 인덱스 값이 음수이면 안되고, 객체 참조는 null이면 안된다.

이런 제약은 반드시 문서화해야 하며 메서드 몸체가 시작되기 전에 검사해야 한다. 즉 오류는 가능한 한 빨리 잡아야 한다. 라는 일반 원칙의 한 사례이기도 하다. 오류를 잡지 못하면 해당 오류를 감지하기 어려워지고, 감지하더라도 오류의 발생 지점을 찾기 어려워진다.

매개변수 검사 방법

매개변수 검사를 제대로 하지 못하면 몇 가지 문제가 생길 수 있다.

1. 메서드가 수행되는 중간에 모호한 예외를 던지며 실패할 수 있다. 더 나아가 잘못된 값을 반환해 메서드와는 관련 없는 오류를 낼 수 있다. 즉 매개변수 검사에 실패하면 실패 원자성을 어기는 결과를 낳을 수 있다.

예를 들어 public과 protected 메소드에서 매개변수 값이 잘못됐을 때 던지는 예외를 문서화해야 한다. 그리고 그 제약을 어겼을 때 발생하는 예외도 함께 기술해야 한다. 다음 예를 보자.

• 매개변수를 통한 예외 코드

/**
* (현재 값 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이 될 수 있다고 알려줄 수도 있지만, 표준적인 방법이 아니다.

그리고 또 다른 방법으로 requireNull 메소드가 있는데 유연하고 사용하기도 편하니, 더 이상 null 검사를 수동으로 하지 않아도 된다. 원하는 예외 메시지도 지정할 수 있고 입력을 그대로 반환하므로 값을 사용하는 동시에 null 검사를 수행할 수 있다.

• requiresNonNull 예제

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

반환값은 그냥 무시하고 필요한 곳 어디서든 순수한 null 검사 목적으로 사용해도 된다.

자바 9에서는 Objects에 범위 검사 기능도 더해졌다. checkFromIndexSize, checkFromToIndex, CheckIndex라는 메서드들인데, null 검사 메서드만큼 유연하지는 않다. 예외 메시지를 지정할 수 없고, 리스트와 배열 전용으로 설계됐다. 또한 닫힌 범위는 다루지 못한다. 그래도 이런 제약이 거림돌이 되지 않는 상황에서는 아주 유용하고 편하다.

assert 단언문

public이 아닌 메소드라면 단언문을 사용해 매개변수 유효성을 검증할 수 있다. 다음 예를 보자.

• 재귀 정렬용 private 도우미 함수

private static void sort (long a[], int offset, int length) {
    assert a != null; // assert 단언문
    assert offset >= 0 && offset <= a.length;
    assert length >= 0 && length <= a.length - offset;
  ... // 계산 수행
}

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

1. 실패하면 AssertionError를 던진다.
2. 런타임에 아무런 효과도, 아무런 성능 저하도 없다. (단, java를 실행할 때 명령줄에서 -ea 혹은 --enableassertions 플래그 설정하면 런타임에 영향을 준다.)

정리

메소드가 직접 사용하지는 않으나 나중에 쓰기 위해 저장하는 매개변수는 특히 더 신경 써서 검사해야 한다. 그리고 생성자 매개변수의 유효성 검사는 클래스 불변식을 어기는 객체가 만들어지지 않게 해야 한다.

메서드 몸체 실행 전에 매개변수 유효성을 검사해야 한다는 규칙에도 예외는 있다.

1. 유효성 검사 비용이 지나치게 높거나 실용적이지 않을 때
2. 계산 과정에서 암묵적으로 검사가 수행될 때

이 두 가지이다.

Collections.sort(List)처럼 객체 리스트를 정렬하는 메서드를 생각해 보면, 리스트 안의 객체들은 모두 상호 비교될 수 있어야 하며, 정렬 과정에서 이 비교가 이루어진다. 만약 상호 비교될 수 없는 타입의 객체가 들어 있다면 그 객체와 비교할 때 ClassCastException이 발생할 것이다. 따라서 비교하기 앞서 리스트 안의 모든 객체가 상호 비교될 수 있는지 검사해봐야 별다른 실익이 없다. 하지만 암묵적 유효성 검사에 너무 의존했다가는 실패 원자성을 해칠 수 있으니 주의해야 한다.

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