매개변수가 유효한지 검사하라 - [8장. 메서드(아이템49)]

  메서드나 생성자를 작성할 때면 그 매개변수들에 어떤 제약이 있을지 생각해야 한다. 이를 위한 원칙 2가지를 살펴보자.

 

📙 1. 원칙 1 : 오류는 가능한 한 빨리 (발생한 곳에서) 잡아야 한다.

  오류를 발생한 즉시 잡지 못하면 해당 오류를 감지하기 어려워지고, 감지하더라도 오류의 발생 지점을 찾기 어려워진다.

매개변수 검사를 제대로 하지 못하면 아래와 같은 문제가 발생할 수 있다.

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

  이러한 문제를 예방하고자 public과 protected 메서드는 매개변수 값이 잘못됐을 때 던지는 예외를 문서화해야 한다. 또한, 매개변수의 제약을 문서화한다면 그 제약을 어겼을 때 발생하는 예외도 함께 기술해야 한다.

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

 

📙 2. 원칙 2 : 나중에 쓰려고 저장하는 매개변수의 유효성을 검사하라.

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

  List를 반환하는 메서드가 있다고 해보자. null 검사를 생략한 경우, 클라이언트는 돌려받은 List를 사용하려고 할 때 비로소 NullPointException이 발생한다. 그러면 이 List를 어디서 가져왔는지 추적하기 어려워 디버깅이 상당히 괴로워지게 된다.

  물론 해당 원칙의 아래와 같은 예외도 존재한다.

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

 

  정리하자면, 메서드나 생성자를 작성할 때면 그 매개변수들에 어떤 제약이 있을지 생각해야 한다. 그리고 그 제약들을 문서화하고 메서드 코드 시작 부분에서 명시적으로 검사해야 한다.

 

 

해당 글은 Joshua Bloch 님의 'Effective Java 3/E'를 참고하였습니다.