Effective Java/정리

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

UroJem 2023. 7. 11. 01:19

메서드와 생성자에서 매개변수의 값이 인덱스로 사용될 때는 음수이면 사용할 수 없고 객체가 넘어올 경우 null이라면 참조하여 사용할 경우 NullPointerException이 나게된다.

이와 같이 매개변수 값이 특정 조건을 만족해야 하는 경우가 왕왕 있다.

이런 제약은 반드시 문서화해야하며 메서드 로직이 본격적으로 시작 되기 전에 검사되어야 한다.

이는 "오류는 가능한 빨리 발생한 곳에서 잡아야 한다"는 일반 원칙의 한 사례이기도 하다.

 

매개변수 검사를 제대로 하지 못하면 몇 가지 문제가 생길 수 있다.

  1. 메서드가 수행되는 중간에 모호한 예외를 던지며 실패할 수 있다.
  2. 더 나쁜 상황은 메서드가 잘 수행되지만 잘못된 결과를 반환할 때다.
  3. 한층 더 나쁜 상황은 메서드는 문제없이 수행됐지만, 어떤 객체를 이상한 상태로 만들어놓아서 미래의 알 수 없는 시점에 이 메서드와 상관없는 오류를 낼 때다.
  4. 다시 말해 매개변수 검사에 실패하면 실패 원자성(failure atomicity)을 어기는 결과를 낳을 수 있다.

 

public과 protected 메서드는 매개변수 값이 잘못됐을 때 던지는 예외를 문서화해야 한다.(@throws 자바독 태그 사용)

매개변수의 제약을 문서화한다면 그 제약을 어겼을 때 발생하는 예외도 함께 기술해야 API 사용자가 제약을 지킬 가능성을 크게 높일 수 있다.

m이 null일 경우 m.signum() 호출 시 NullPointerException을 던진다.

메서드에서 설명하지 않는다면 클래스 수준에서 설명했을 수도있다.

클래스 수준 주석은 그 클래스의 모든 public 메서드에 적용되므로 각 메서드에 일일이 기술하는 것보다 훨씬 깔끔함 방법이다.

BigInteger의 클래스 주석

 

 

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

원하는 예외 메세지를 지정할 수 있고 입력값을 그대로 반환하므로 값을 사용하는 동시에 null 검사를 수행할 수 있다.

 

requiredNonNull 메서드를 사용하기 전에는 매개변수로 널 객체를 전달해도 method1, method2에 아무 이상 없다가 실제  method3에서 참조하여 사용하게 됐을 때 NullPointerException이 난다.

 

requiredNonNull을 사용하면 빠른 실패가 발생되고 원한다면 별도의 메세지를 출력해볼 수 있다.

 

String nullString = null;

if (nullString == null) {
    throw new NullPointerException("입력이 null 입니다!");
}
String nullString = null;

Objects.requireNonNull(nullString, "입력이 null 입니다!");

if문 분기처리보다 명시성, 가독성이 좋다.

 

https://hudi.blog/java-requirenonnull/

 

[Java] Objects.requireNonNull 은 왜 사용할까?

학습 동기 이펙티브 자바를 읽다보면 null 에 대한 체크를 위해 대부분 Objects 클래스의 requireNonNull 을 사용한다. 또한 다른 우테코 페어의 코드를 읽다보면, 가끔 requireNonNull 로 널 체크를 하는 코

hudi.blog

 

 

공개되지 않은 메서드라면 패키지 제작자가 메서드가 호출되는 상황을 통제할 수 있다.

요직 유효한 값만이 메서드에 넘겨지리라는 것을 패키지 제작자가 보증할 수 있고, 그렇게 해야한다. 

assert를 사용해 매개변수 유효성을 검증할 수 있다.

assert는 자바 1.4부터 키워드로 등록되었는데 이전 버전에서는 "assert" 이름의 변수, 매서드가 있을 수 있어 이전버전의 코드를 최신 JVM버전과 사용했을 때 충돌할 수 있어서 기본적으로 실행이 안되게 되어있다.

Assertion은 디버깅 용도로 사용되어서 JVM 기본 설정으로 프로그램을 실행하게 되면 assert문은 모두 실행에서 제외된다. assert가 동작하게 하려면 실행시 -ea 옵션을 사용해서 실행.

이클립스에서 VM 옵션주기

 

여기서의 핵심은 이 단언문들은 자신이 단언한 조건이 무조건 참이라고 선언한다.

실패하면 AssertError를 던지고 런타임에 아무런 효과도, 성능저하도 없다.

 

https://www.baeldung.com/java-assert

 

 

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

여러 메서드를 거쳐 비로소 사용하려고 할때 NullPointerException이 발생한다면 이 객체를 어디서 가져왔는지 추적하기 어려워 디버깅이 상당히 괴로워진다.

 

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

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

 

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

  • 유효성 검사비용이 지나치게 높거나 실용적이지 않을 때
  • 계산 과정에서 암묵적으로 검사가 수행될 때
    • 예를 들어 Collections.sort(List)는 정렬과정에서 상호 비교될 수 없는 타입의 객체가 들어있다면 ClassCastException을 던진다.

 

때로는 계산 과정에서 필요한 유효성 검사가 이뤄지지만 실패했을 때 잘못된 예외를 던지기도 한다.

계산 중 잘못된 매개변수 값을 사용해 발생한 예외와 API 문서에서 던지기로 한 예외가 다를 수 있다.

이런경우 예외번역 관용구를 사용하여 API문서에 기재된 예외로 번역해줘야 한다.

 

예외 번역(exception translation): 상위 계층에서 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꾸어 던지는 것.

try {
	... // 저수준 추상화 이용.
} catch (LowerLevelException e) {
	throw new HigherLevelExcetpion(...);
}

 

메서드가 건네받은 값으로 무언가 제대로 된 일을 할 수 있다면 매개변수 제약을 적을수록 좋다.

 

 

핵심정리

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

저작자표시 비영리 변경금지