아이템49 매개변수가 유효한지 검사하라

Effective Java 3e 아이템 49를 요약한 내용 입니다.

메서드와 생성자 대부분은 입력 매개변수의 값이 특정 조건을 만족하기를 바란다. 이는 "오류는 가능한 한 빨리 (발생한 곳에서) 잡아야 한다"는 일반 원칙의 한 사례이기도 하다. 오류를 발생한 즉시 잡지 못하면 해당 오류를 감지하기 어려워지고, 감지하더라도 오류의 발생 지점을 찾기 어려워진다.

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

1. 메서드가 수행되는 중간에 모호한 예외를 던지며 실패할 수 있다.

2. 더 나쁜 상황은 메서드가 잘 수행되지만 잘못된 결과를 반환할 때다

3. 한층 더 나쁜 상황은 메서드는 문제없이 수행됐지만, 어떤 객체를 이상한 상태로 만들어놓아서 미래의 알 수 없는 시점에 이 메서드와는 관련 없는 오류를 낼 때다.

public과 protected 메서드는 매개변수 값이 잘못됐을 때 던지는 예외를 문서화해야 한다.(@throws 자바독 태그를 사용하면 된다) 자바 7에 추가된 java.util.Objects.requireNonNull 메서드는 유연하고 사용하기도 편하니, 더 이상 null 검사를 수동으로 하지 않아도 된다.

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

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

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를 던진다.

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

생성자 유효성 검사는 다르다

생성자 매개변수의 유효성 검사는 클래스 불변식을 어기는 객체가 만들어지지 않게 하는 게 꼭 필요하다.

public class Person
	public Person(String name, Integer age) {
	    Validate.notNull(name, "name can't be null");
	    Validate.notNull(age, "age can't be null");
	    ...
	}
}

메서드 매개변수 유효성 검사에도 예외는 있다

유효성 검사 비용이 지나치게 높거나 실용적이지 않을 때, 혹은 계산 과정에서 암묵적으로 검사가 수행될 때다. 예를 들어 Collections.sort(List)처럼 객체 리스트를 정렬하는 메서드의 경우 상호 비교될 수 없는 타입의 객체가 들어 있다면 그 객체와 비교할 때 ClassCastException을 던질 것이다. 따라서 비교하기 앞서 리스트 안의 모든 객체가 상호 비교될 수 있는지 검사해봐야 별다른 실익이 없다.

public class Collectionsorting 
{ 
    public static void main(String[] args) 
    { 
        // Create a list of strings 
        ArrayList<String> al = new ArrayList<String>(); 
        al.add("Geeks For Geeks"); 
        al.add("Friends"); 
        al.add("Dear"); 
        al.add("Is"); 
        al.add("Superb"); 
  
        /* Collections.sort method is sorting the 
        elements of ArrayList in ascending order. */
        Collections.sort(al); 
  
        // Let us print the sorted list 
        System.out.println("List after the use of" + 
                           " Collection.sort() :\\n" + al); 
    } 
}

잘못된 오해

이번 아이템을 "매개변수에 제약을 두는 게 좋다"고 해석해서는 안된다. 사실은 그 반대다. 메서드는 최대한 범용적으로 설계해야 한다. 메서드가 건네받은 값으로 무언가 제대로 된 일을 할 수 있다면 매개변수 제약은 적을수록 좋다. 하지만 구현하려는 개념 자체가 특정한 제약을 내재한 경우도 드물지 않다.

정리

메서드나 생성자를 작성할 때면 그 매개변수들에 어떤 제약이 있을지 생각해야 한다. 그 제약들을 문서화하고 메서드 코드 시작 부분에서 명시적으로 검사해야 한다. 이런 습관을 반드시 기르도록 하자. 그 노력은 유효성 검사가 실제 오류를 처음 걸러낼 때 충분히 보상받을 것이다.