DEV ℧ Developer Diary

[EffectiveJava] item49 - 매개변수가 유효한지 검사하라

18 Jun 2023

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

  • index가 음수인 경우
  • 객체 참조가 null 인경우

이런 제약은 반드시 문서화해야 하며 메서드 몸체가 시작되기 전에 검사해야 한다.

이는 “오류는 가능한 한 빨리 (발생한 곳에서) 잡아야 한다”(fail-fast) 일반 원칙의 한 사례 이기도 하다. 즉시 잡지 못하면 감지하기 어려워지고, 감지하더라도 발생지점을 찾기 어려워 지기 때문이다.

메개변수 유효검사의 필요성

메서드 몸체가 실행되기 전에 매개변수를 확인한다면 잘못된 값이 넘어왔을 때 즉각적이고 깔끔한 방식으로 예외를 던질 수 있다.

제대로 검사하지 못할시 아래와 같은 문제점이 발생할 수 있다.

  1. 메서드가 수행되는 중간에 모호한 예외를 던지며 실패할 수 있다.
  2. 메서드가 잘 수행되었지만 잘못된 결과를 반환할 수 있다.
  3. 메서드는 문제없이 수행됐지만, 어떤 객체를 이상한 상태로 만들어 추후 알수 없는 시점에 이 메서드와 관련없는 오류가 발생할 수 있다.

문서화의 필수성

public과 protected 메서드는 매개변수 값이 잘못됐을 때 던지는 예외를 문서화(@throws) 해야 한다.

보통은 IllegalArumentException, IndexOutOfBoundsException, NullPointerException 중 하나가 될 것이다.

/**
 * (현재 값 mod m) 값을 반환한다. 이메서드는
 * 항상 음이 아닌 BigInteger를 반환한다는 점에서 remainder 메서드와 다르다
 *
 * @param m 계수 (양수여야 한다.)
 * @return 현재 값 mod m
 * @throws ArithmeticException m이 0보다 1작거나 같으면 발생한다.
 */
public BigInteger mod(BigInteger m) {
    if (m.signum() <= 0)
        throw new ArithmeticException("계수(m)는 양수여야 합니다. " + m);
    ... // 계산 수행
}

이 메서드에서는 만약 BigInteger m이 null 이라면 m.signum() 을 호출할 때 NullPointerException을 던질 것이다.

그런데 따로 문서에는 해당 내용이 기술 되어 있지 않다. 그 이유는 이 설명을 (개별 메서드가 아닌) BigInteger 클래스 수준에서 기술했기 때문이다.

이에 대한 대체방안으로 @Nullable을 이용해 null이 될 수 있다고 알려줄 수도 있지만, 표준적인 방법이 아니다.

requireNonNull

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

원하는 예외 메시지도 지정할 수 있다. 또한 입력을 그대로 반환하므로 값을 사용하는동시에 null 검사를 수행할 수 있다.

자바의 null 검사 기능 사용하기

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

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

자바 9에서 추가된 검사

자바 9에서는 Objects 에 범위 검사 기능도 더해졌다. checkFromIndexSize, checkFromToIndex, checkIndex라는 메서드들인데, null 검사 메서드 만큼 유연하지는 않다.

그래도 이런 제약이 걸림돌이 되지 않는 상황에서는 아주 유용하고 편하다.

단언문(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;
    ... // 계산 수행
}

여기서의 핵심은 이 단언문들은 자신이 단언한 조건이 무조건 참이라고 선언한다는 것이다.

단언문은 몇 가지 면에서 일반적인 유효성 검사와 다르다.

  1. 실패하면 AssertionError을 던진다.
  2. 런타임에 아무런 효과도, 아무런 성능 저하도 없다.

매개변수 검사의 중요성

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

int 배열의 List 뷰(view)를 반환하는 메서드에서 Objects.requireNonNull과 같은 null검사가 생략될 경우, null을 건네면 즉시 에러를 반환하는 것이 아니라 List를 생성할때 비로소 NullPointerException이 발생할 것이다.

이때가 되면 이 List를 어디서 가져왔는지 추적하기 어려워 디버깅이 상당히 괴로워 질 수 있다.

매개변수 검사 규칙의 예외

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

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

예를 들면 Collections.sort(List)의 경우로, 만약 상호 비교될 수 없는 타입의 객체가 들어있다면 그 객체와 비교할 때 ClassCastException을 던질 것이다. 따라서 비교하기 앞서 리스트 안의 모든 객체가 상호 비교될 수 있는지 검사해봐야 별다른 실익이 없다.

매개변수의 제약?

이번 주제를 “매개변수에 제약을 두는 게 좋다” 고 해석해서는 안 된다. 사실은 그 반대다.

메서드는 최대한 범용적으로 설계해야 한다. 메서드가 건네받은 값으모 무언가 제대로 된 일을 할 수 있다면 매개변수 제약은 적을 수록 좋다.

하지만 구현하려는 개념 자체가 특정한 제약을 내재한 경우도 드물지 않다.

Related posts