[Effective Java] Item 49. 매개변수가 유효한지 검사하라

개요

 어떤 메서드를 구현할 때 매개변수가 유효하다는 것을 당연하게 여기곤 한다. 이렇게 가정한 상태에서 비지니스 로직을 구현하곤 한다. 어떤 이들은 이러한 사태를 방지하기 위해 생성자나 메서드 호출 부 앞단에 유효성 검사하는 메서드를 추가하기도 한다.

 어찌됐든, 유효한 매개변수를 당연시하게 될 경우 여러 문제가 발생할 수 있다. 메서드 수행 중간에 개발자가 생각지 못했던 예외가 발생한다거나, 메서드가 잘 수행됐지만 잘못된 값을 반환하거나 하는 등의 문제이다.

 

매개변수로 인한 예외는 문서화하라

public 과 protected 메서드는 매개변수 값이 잘못됐을 때 던지는 예외를 문서화 하길 권장하고 있다. @throws 자바독 태그를 사용하면 된다. 이렇게 문서화를 하는 이유는 유효하지 않은 매개변수에 대한 것을 개발자도 인지하고 있고, 다른 개발자에게도 알려주기 위함이라고 생각한다. 왜? 접근제어자에 따라 어디서든 호출될 수 있기 때문이다.

 

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

        return m.mod(m);
    }

 

 

m 이 null인 경우도 있잖아요?? 그럼 NullPointException 도 추가해야하는거 아닌가요?

추가하지 않는다. 그 이유는 이 설명을 mod 와 같은 개별 메서드가 아닌 매개변수 자체, 즉, BigInteger 클래스 수준에서 기술했기 때문이다. 클래스 수준 주석은 그 클래스의 모든 public 메서드에 적용되므로 각 메서드에 일일이 기술하는 것보다 깔끔하다.

 

아래는 BigInteger 클래스 내에 주석을 보면 [이 클래스의 모든 메서드와 생성자는 입력 매개변수에 대해 null 개체 참조가 전달되면 NullPointerException 이 발생한다]고 기재되어 있다.

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

 

어찌됐던 Null 검사는 해야하지 않나요?

 

순수하게 null을 체크하고자 한다면 자바 7에 추가된 java.util.Objects.requireNonNull 메서드를 사용하면 된다. a != null 과 같은 방법보다 훨씬 유연한 방법이다. 원하는 예외 메시지를 지정할 수도 있고, 입력을 그대로 반환하니 이를 활용할 수도 있다. 반환 값을 무시하고 순수한 null 검사 목적으로 사용해도 된다.

 

Null Check + 예외 메시징 처리

Integer value = null;
Objects.requireNonNull(value, "value 값이 null입니다.");

 

Null Check 와 예외 메시징 처리를 동시에 수행한다.

 

 

체크 입력 값 그대로 반환

Integer value2 = 3;
Integer value3 = Objects.requireNonNull(value2, "value 값이 null입니다.");
System.out.println(value3); // 3

 

private 는 매개변수로 인한 예외를 문서화하지 않나요?

굳이 문서화할 필요가 없다. 왜냐하면 public 이나 protected 는 외부에서 호출이 가능하다. 특히 public 은 어디서든 호출이 가능하기 때문에 매개변수로 인한 예외 가능성이 다분하다. 이에 반해 private 는 클래스 내에서만 호출 가능하다. 즉, 유효한 매개변수가 들어온다는 것을 충분히 보증할 수 있고, 또 그렇게 해야 한다. 이런 상황에서는 예외가 아닌 단언문(assert)를 사용해 매개변수 유효성을 검증할 수 있다.

 

private static void sort(long a[], int offset, int length){
    assert a != null;
    assert offset >= 0;
    assert length >= 0;
    ...
}

 

여기서 핵심은 이 단언문들은 자신이 단언한 조건이 무조건 참이라고 선언하는 것이다. 단언문은 몇가지 면에서 유효성 검사와 다르다. 첫째, 실패하면 AssertionError를 던진다. 둘째, 런타임에 아무런 효과도, 성능 저하도 없다.

 

그럼 무조건 매개변수 유효성 검사를 해야하나요?

예외는 있다. 유효성 검사 비용이 지나치게 높거나 계산 과정에서 암묵적으로 검사가 수행될 때다. 예를들어 Collections.sort(List) 처럼 객체 리스트를 정렬하는 메서드의 경우 리스트 안의 객체들은 모두 상호 비교될 수 있어야 하며, 이 과정에서 사실상 유효성 검사가 이루어진다. 그 객체와 비교할 때 비교될 수 없는 타입의 데이터가 있을 경우 ClassCastException 이 발생하기 때문이다.

 sort() 메서드 실행 초반부에 파라미터로 들어온 List 에 대한 유효성 검사를 한다면, 사실상 두 번의 유효성 검사를 한 격이다. 단, 이런 암묵적 유효성 검사의 너무 의존하는 것은 좋지 않다.

 

정리

 메서드나 생성자를 작성할 때 매개변수들에 어떤 제약이 있을지 생각해야 한다. 그 제약들을 문서화하고 메서드 코드 시작 부분에서 명시적으로 검사해야 한다. 이 노력은 유효성 검사가 실제 오류를 처음 걸러낼 때 보상받을 수 있다. 하지만 이번 아이템을 "매개변수에 제약을 두는게 좋다"로 해석하면 안된다. 메서드는 최대한 범용적으로 설계하는게 좋기 때문이다.