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

이번 아이템은 워낙 내용이 길어서 가독성을 높이기 위해, 스스로 소제목을 달아서 구분했습니다.

보다 읽는 사람이 명확하고 쉽게 이해되기를 빕니다.

 

 매개변수에 대한 일반 원칙

 

 메서드와 생성자의 매개변수 값은 음수이면 안되며, 객체 참조는 null이 아니어야 한다. 이런 제약은 반드시 문서화 해야 하며 메서드 몸체가 시작되기 전에 검사해야 한다. 이는 "오류는 가능한 빨리 발생한 곳에서 잡아야 한다"는 일반 원칙의 한 사례이다.

 

매개변수의 검사를 간과하면 생기는 문제

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

2. 메서드가 잘 수행되지만 잘못된 결과를 반환한다.

3. 메서드가 문제없이 수행됐지만, 어떤 객체를 이상한 상태로 만들어놓아서 미래의 알 수 없는 시점에 문제가 발생한다.

 

public, protected 메서드의 매개변수가 잘못됐을 때 -> 주석을 달자. 예외상황도 함께

 매개변수 값이 잘못됐을 때 던지는 예외를 문서화해야 한다.(@throws 자바 독 태그를 사용한다. 아이템 74)  보통은 IllegalArgumentException, IndexOutOfBoundsException, NullPointerException 중 하나가 될 것이다.(아이템 72) 매개변수의 제약을 문서화한다면, 그 제약을 어겼을 때 발생하는 예외도 함께 기술해야 한다.

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

 이 메서드는 m이 null이면 m.signum() 호출 떄 NullPointerException을 던진다. 그런데 "m이 null일 때 NullPointerException을 던진다"라는 말은 메서드 설명 어디에도 없다. 그 이유는 이 설명을 개별 메서드가 아닌 BigInteger 클래스 수준에서 기술했기 때문이다. 클래스 수준 주석은 그 클래스의 모든 public 메서드에 적용되므로 각 메서드에 일일이 기술하는 것보다 훨씬 깔끔한 방법이다.

 

null에 대한 처리법은?

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

 

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

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

 

 자바 9에서는 Objects에 범위 검사 기능도 더해졌다...

 

공개되지 않은 메서드의 경우

 공개되지 않은 메서드라면 패키지 제작자인 프로그래머가 메서드가 호출되는 상황을 통제 할 수 있다. 오직 유효한 값만이 메서드에 넘겨지리라는 것을 보증할 수 있고, 그렇게 해야한다. 다시 말해 public이 아닌 메서드라면 단언문(assert)을 사용해 매개변수 유효성을 검증할 수 있다.

 

재귀 정렬용 private 도우미 함수

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;
    //Todo : 해야할 일...
}

 

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

 

매개변수는 대부분 언제든지 빠르게 검사한다

 메서드가 직접 사용하지 않으나 나중에 쓰기 위해 저장하는 매개변수는 특히 더 신경 써서 검사해야 한다. 입력받은 int 배열의 List 뷰를 반환하는 메서드는 null 검사를 수행하므로 클라이언트가 null을 건네면 NullPointerExcpetion을 던진다.만약 이 검사를 생략했다면 새로 생성한 List 인스턴스를 반환하는데, 클라이언트가 돌려받은 List를 사용하려 할 떄 비로소 NullPointerException이 발생한다. 이때가 되면 이 List가 어디서 가져왔는지 추적하기 어려워 디버깅이 상당히 괴로워진다.

 

빠른 매개변수 검사의 예외사항

 유효성 검사 자체가 비용이 지나치게 높거나 실용적이지 않을 때, 계산 과정에서 암묵적으로 검사가 수행될 때다. Collections.sort(List)의 경우 상호 비교될 수 없는 타입의 객체가 들어있다면 그 객체와 비교할 때 ClassCastException을 던질 것이다. 따라서 미리 리스트 안의 모든 객체에 대해 상호 검사해봐야 실익이 없다. 하지만 이것에 너무 의존하면 실패 원자성(아이템76)을 해칠 수도 있다.

 

결과 실패시 예외가 발생할 수도

 때로는 계산과정에서 필요한 유효성 검사가 이뤄지지만 실패했을 떄 잘못된 예외를 던지도 한다. 잘못된 매개변수 값을 사용해서 발생한 예외와 API 문서에서 던지기로 한 예외가 다를 수 있다. 이런 경우에는 아이템 73에서 설명하는 예외번역 관용구를 사용하여 API 문서에 기재된 예외로 번역해준다.

 

결론

 이번 아이템을 "매개변수에 제약을 두는 게 좋다"고 해석하면 안된다. 그 반대로 "메서드는 최대한 범용적으로 설계한다"를 따라야 한다.

 

 

*느낀점 

굉장히 중요한 내용인 만큼 분량이 많았다. 매개변수의 유효성 검사는 그 메서드의 정상적인 실행과 종료에 엄청나게 중요한 요인이 될 것이다. 오류를 잡는 것은 당연한 것이며, 과연 어디서 어떻게 잡는 것이 가장 효율적인지 고민해야 한다. 실제적으로 발생할 수 있는 오류에 대해서 인지하고 미리 예외를 만들 수 있도록 한다. 이 예외에 대한 주석, 설명은 필수이다. 또한, 무조건적으로 빠르게 검사하는 것이 아닌 암묵적인 검사의 상황과, 때로는 예상되지 않는 실패의 경우 던지는 예외에 대해서도 고려해야 한다. 너무 매개변수에 집착해서 제약을 두는 것이 아니라 범용적으로 설계할 것!