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

[Irisation23]

📝 구성

• 1. 매개변수가 유효한지 검사하라
• 2. 왜 매개변수를 검증해야 하는가?
• 3. 매개변수 검증 방법
  • 3.1 public과 protected 메서드는 던지는 예외를 문서화해야한다.
  • 3.2 assert
  • 3.3 매개변수와 생성자
  • 3.4 그외
  • 3.5 What about null parameters?
• 4. 핵심 정리 📚
• 5. 회고 🧹

Table of contents generated with markdown-toc

---

1. 매개변수가 유효한지 검사하라

메서드와 생성자 대부분은 입력값이 특정 조건을 만족하기를 바란다.

private List<String> names;

// ...

public String getNameOf(int index) {
    return names.get(index);
}

위와 같이 이름을 관리하고 있는 클래스가 있고 관리하고 있는 이름의 인덱스값을 통해 값을 조회하는 getNameOf가 있다고 가정한다. 이때 index가 음수이거나 names의 크기보다 크다면 에러가 발생한다.

이런 제약은 반드시 문서화해야하며 메서드 바디가 실행되기 전에 검증을 해야한다.

오류는 가능한 한 빨리 잡아야한다.

오류를 발생한 시점에서 바로 잡지 못하면 해당 오류를 감지하기 어려워지고 오류의 발생 지점을 찾기 힘들어진다.

따라서 메서드 바디가 실행되기 전에 매개변수를 확인한다면 잘못된 값이 넘어왔을때 즉각적이고 깔끔한 방식으로 예외를 던질 수 있다.

2. 왜 매개변수를 검증해야 하는가?

매개변수 검증이 이뤄지지 않는다면 메서드가 실행되는 중간에 모호한 예외를 던지며 실패할 수 있다.
또는 메서드가 제대로 수행 되더라도 예상치 못한 결과를 도출할 수 있다.

특히 후자의 경우가 문제가 되는데 전자는 예외를 던지며 에러로그를 남기면 해결할 수 있지만, 후자는 실제 데이터 정합성이 깨진것을 확인했을때 인지가 가능하기 때문이다.

이렇게 매개변수 검증에 실패하면 실패하면 실패 원자성을 어기는 결과가 나타난다.

• 실패 원자성은 item76에서 다룸

호출된 메서드가 실패하더라도 해당 객체는 호출 전의 상태를 유지해야한다.

3. 매개변수 검증 방법

3.1 public과 protected 메서드는 던지는 예외를 문서화해야한다.

public과 protected는 외부 접근도가 높은 제어자이므로 이들 메서드에는 @throws Javadoc 태그를 통해 문서화해야한다.

/**
 * Returns a BigInteger whose value is {@code (this mod m}).  This method
 * differs from {@code remainder} in that it always returns a
 * <i>non-negative</i> BigInteger.
 *
 * @param  m the modulus.
 * @return {@code this mod m}
 * @throws ArithmeticException {@code m} &le; 0
 * @see    #remainder
 */
public BigInteger mod(BigInteger m) {
    if (m.signum <= 0)
        throw new ArithmeticException("BigInteger: modulus not positive");

    BigInteger result = this.remainder(m);
    return (result.signum >= 0 ? result : result.add(m));
}

위는 BigInteger의 mod()로 매개변수 m이 0 이하일때 ArithmeticException이 발생하는 것을
@throwsJavadoc 태그로 명시하고 있다.

참고로 모든 메서드에 적용되는 문서화를 하고 싶다면 클래스 수준에서 Javadoc 을 작성하면 된다.

public, protected 이외에 package pirvate, private는 개발자가 스스로 메서드가 호출되는 상황을 통제할 수 있다. 즉, 유효한 값이 들어온다는 것을 보장할 수 있다.

3.2 assert

assert 예약어

public, protected 메서드 이외에는 assert 단언문을 통해서 매개변수 유효성을 검증할 수 있다.

private String get(int index) {
    assert index >= 0;
    return names.get(index);
}

assert 단언문은 자신이 선언한 조건이 무조건 참이어야 다음 로직을 수행한다.
그렇지 않으면 AssertionException을 던진다.

assert는 Java 실행시 -ea 또는 --enableassertions 옵션을 주지않으면 런타임에 아무런 영향을 주지 않으며 성능 저하도 없다.

보통 개발 중에 테스팅하는 목적으로 사용된다.

3.3 매개변수와 생성자

메서드에서 직접 사용하지는 않지만 나중에 사용하기 위해서 필드로 저장하는 경우는 더더욱 철저히 검사가 필요하다. 이때 검사가 제대로 이뤄지지 않으면 null이 필드에 할당되거나 컬렉션이라면 컬렉션 안에 null이 들어갈 수 있다. 그리고 이 null을 사용함으로써 NullPointerException이 발생할 수 있다.
NullPointerException은 디버깅이 힘들다.

생성자는 나중에 쓰려고 저장하는 매개변수의 유효성을 검사하라 원칙의 특수사례이다. 생성자 매개변수의 유효성 검사는 클래스 불변식을 어기는 객체가 만들어지지 않게 하는데 필수이다.

3.4 그외

유효성 검사 비용이 지나치게 높거나 실용적이지 않다면 예외적으로 유효성 검사에 대해 고려해 볼 수있다.

대신 Exception에 대한 대응 방안을 반드시 두어야 할 것

암묵적으로 유효성 검사를 하는 경우

Collection의 sort()처럼 컬렉션에 들어있는 객체의 타입이 다르면 ClassCastException이 발생한다. 로직이 수행되면서 유효성에 어긋나는 경우 Exception을 던지므로 실행 전에 유효성 검사를 수행할 필요는 없다.

다만, 암묵적 유효성 검사에 너무 의존하면 실패 원자성을 해칠 수 있다.

3.5 What about null parameters?

Effective Java에서는 Java 7에 추가된 java.util.Objects.requireNonNull를 유연하고 사용하기 편한 메서드로 소개하고 있다.

public static <T> T requireNonNull(T obj) {
    if (obj == null)
        throw new NullPointerException();
    return obj;
}

java.util.Objects.requireNonNull도 결국에는 매개변수 obj가 null이라면 그대로 NullPointerException을 일으킨다.

java.util.Objects.requireNonNull을 활용한다면 다음과 같이 null일 때 default 값을 반환할 수 있도록 만들어 보는 활용 방안을 생각해 볼 수있다.

public static <T> T requireNonNullElse(T obj, T defaultObj) {
    try {
        Objects.requireNonNull(obj)
        return obj;
    } catch(NullPointerException e) {
        log.error("{} is null", obj);
        return defaultObj;
    }
}

Java9에는 requireNonNullElse 를 지원하여 Java API에서 지원한다.

Java 9에는 requireNonNullElse 이외에도 checkFromIndexSize, checkFromToIndex,
checkIndex 등 다양한 검사가 추가 되었다.

---

4. 핵심 정리 📚

• 메서드나 생성자를 작성할 때 매개변수의 제약에 대한 고민을 해야한다.
• 제약을 문문서화하고 메서드 코드 시작 부분에서 명시적으로 검사해야 한다.

---

5. 회고 🧹

2023.02.11 토

• 과거에 발표했던 Validation 그 끝은 어디인가 Front 편을 담당했을 때 느낀점과는 사뭇 달랐다.
• 예외를 파라미터단에서 Spring @Valid 를 사용했던 기억이 나는데, 당시에는 왜 파라미터 단에서 먼저 검증하는 지에 대해 의문없이 사용했지만 이번 정리를 통해 유효성 검사는 빠르면 빠를 수록 좋다는 것을 알게 되었다.
• 자바독, README.md 등등 문서화는 귀찮기 전에 항상 먼저 작성하는 버릇을 들이도록 하자 (💨 언젠간 태풍이 되어 몰아친다....)

---

[jinan159]

매개변수 유효성 검사는 사실 당연하게 하고있었던 것 같습니다.
그런데 public, protected 메서드의 경우에는 던지는 예외를 문서화하라는 것은 조금 찔리네요.
귀찮아서 잘 안했었는데 신경써서 문서화 해야겠습니다 ㅎㅎ

[chikeem90]

사실 실무하면서 javadoc으로 문서화하는 경우가,, 드문 거 같긴 하네요,,
다양한 요구사항에 따라 메서드 시그니처나 파라미터 타입이나 리턴 타입이 바뀌는 경우가 종종 있어서 javadoc도 하나의 관리포인트가 되어버리기 때문에,,
메서드를 잘 나누고 해당 메서드가 어느 역할인지 네이밍을 잘 선택하는 것이 가장 중요한 거 같긴 합니다. (이건 기본 전제이긴 하지만,,)

assert는 Java 실행시 -ea 또는 --enableassertions 옵션을 주지않으면 런타임에 아무런 영향을 주지 않으며 성능 저하도 없다.

이건 처음 알았네요,,

[jinan159]

말씀하신 내용도 정말 공감이 가네요..
관리 안된 주석은 없으니만 못하니말이죠..
여러 방면으로 생각 잘 해봐야겠습니다 ㅎㅎ

[Irisation23]

동의 합니다. 행여나 바뀌면 Docs 리팩토링도 해야하는 상황이 있네요 ㅠ

[Irisation23]

https://offbyone.tistory.com/294

위 링크는 assert IDE 설정 방법이자 각 설정이 뭘 의미하는지 알려주는 블로그구요. 무려 이클립스 세팅 방법이라 조금 서운해서 아래 인텔리제이 설정 링크 추가합니다.

https://se-education.org/guides/tutorials/intellijUsefulSettings.html

개념은 위의 tistory가 좋아보이구요 사용할 때는 아래의 intellij 링크 봐주시면 좋을것 같습니다.

감사합니다. 👍