Java/Effective Java

[Effective Java] Item 49. 매개변수가 유효한지 검사하라

안도일 2023. 7. 16. 15:28

메서드와 생성자 대부분은 입력 매개변수의 값이 특정 조건 (인덱스 값이 음수이면 안되고, 객체 참조는 null이 아니어야 한다)을 만족하길 바라고 이런 제약은 반드시 문서화해서 메서드 몸체가 시작되기 전에 검사해야 한다.

 

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

 

 

매개변수 검사를 제대로 하지 못하면 생기는 문제

 

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

 

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

 

3. 메서드는 문제없이 수행되지만 어떤 객체를 이상한 상태로 만들어놓아서 미래의 알 수 없는 시점에 이 메서드와는 관련 없는 오류를 낼 수 있다.

 

 

 

매개변수 제약 문서화

 

  • public과 protected 메서드는 매개변수 값이 잘못됐을 때 던지는 예외를 문서화해야 한다.
  • 매개변수의 제약을 문서화한다면 @throws 자바독 태그를 사용하여 그 제약을 어겼을 때 발생하는 예외도 함께 기술해야 한다.

 

 

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

 

 

null 검사 기능

 

  • 자바 7에 추가된 java.util.Objects.requireNonNull 메서드는 유연하고 사용하기도 편하니, 더 이상 null 검사를 수동으로 하지 않아도 된다.
  • 원하는 예외 메시지도 지정할 수 있고, 입력을 그대로 반환하므로 값을 사용하는 동시에 null 검사를 수행할 수도 있다.
  • 반환값은 무시하고 필요한 곳 어디서든 순수한  null  검사 목적으로 사용해도 된다.

 

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

 

 

 

 

범위 검사 기능

 

  • 자바 9에서는 Objects에 범위 검사 기능도 더해졌다.
  • checkFromIndexSize, checkFromToIndex, checkIndex라는 메서드들인데, 예외 메서지를 지정할 수 없고, 리스트와 배열 전용으로 설계됐다.
  • 닫힌 범위(closed range: 양 끝단을 포함하는)는 다루지 못한다.

 

 

단언문

 

public이 아닌 메서드라면 단언문 assert를 사용해 매개변수 유효성을 검증할 수 있다.

 

 

 

단언문은 몇 가지 면에서 일반적인 유효성 검사와 다르다.

  1. 실패하면 AssertionError를 던진다.
  2. 런타임에 아무런 효과도, 아무런 성능 저하도 없다.

 

단언문

단언문 assert은 개발자가 프로그램의 특정 지점에서 조건이 참인지 확인하고, 그렇지 않으면 예외를 발생시키는 데 사용된다.

 

 

추가사항

 

 

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

 

  • 입력받은 int 배열의 List 뷰를 반환하는 메서드를 Objects.requireNonNull을 이용해 null검사를 수행하므로 클라이언트가 null을 건네면 NullPoointerException을 던진다. 
  • 만약 이 검사를 생략했다면 새로 생성한 List 인스턴스를 반환하는데, 클라이언트가 돌려받은 List를 사용하려 할 때 비로소 NullPointerException이 발생한다.  이때가 되면 이 List를 어디서 가져왔는지 추적하기 어려워 디버깅이 어렵다.

 

 

생성자는 "나중에 쓰려고 저장하는 매개변수의 유효성을 검사하라"는 원칙의 특수 사례다.

 

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

 

 

메서드 몸체 실행 전에 매개변수 유효성을 검사해야 한다는 규칙에도 예외는 있다.

 

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

 

ex) Collections.sort(List) 처럼 객체 리스트를 정렬하는 메서드

리스트 안의 객체들은 모두 상호 비교될 수 있어야 하며, 정렬 과정에서 이 비교가 이루어진다.

만약 상호 비교될 수 없다면 그 객체와 비교할 때 ClassCastException을 던질 것이다. 따라서 유효성을 따로 검사하는 실익이 없다.

 

 

결론

 

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