> For the complete documentation index, see [llms.txt](https://incheol-jung.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://incheol-jung.gitbook.io/docs/study/effective-java/undefined-6/49.md).

# 아이템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); 
    } 
}
```

#### 잘못된 오해

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

### 정리

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