아이템 27. 비검사 경고를 제거하라

문법식·2022년 8월 9일
0

Effective Java 3/E

목록 보기
27/52

제너릭을 사용하기 시작하면 수많은 컴파일러 경고를 보게 될 것이다. 비검사 형변환 경고, 비검사 메서드 호출 경고, 비검사 매개변수화 가변변수 타입 경고, 비검사 변환 경고 등이다.
대부분의 비검사 경고는 쉽게 제거할 수 있다. 코드를 다음처럼 잘못 작성했다고 해보자.

Set<Lark> exaltation=new HashSet();

다음과 같은 경고가 뜬다.

Unchecked assignment: 'java.util.HashSet' to 'java.util.Set<Lark>'

아래와 같이 고치면 경고가 사라진다.

Set<Lark> exaltation=new HashSet<Lark>();

위와 같이 타입 매개변수를 명시하지 않고, 아래와 같이 자바 7부터 지원하는 다이아몬드 연산자(<>)만으로 해결할 수 있다.

Set<Lark> exaltation=new HashSet<>();

할 수 있는 한 모든 비검사 경고를 제거해야 한다. 모두 제거한다면 그 코드는 타입 안전성이 보장된다. 즉, 런타임에 ClassCastException이 발생할 일이 없고, 우리가 의도한대로 잘 동작한다고 확신할 수 있다.
경고를 제거할 수 없지만 타입이 안전하다고 확신할 수 있다면 @SuppressWarnings("unchecked")어노테이션을 달아 경고를 숨겨야 한다. 타입 안전성을 검증하지 않고 경고를 숨기면 스스로에게 잘못된 보안 인식을 심어주는 꼴이다. 코드가 경고 없이 컴파일되겠지만, 런타임에는 여전히 ClassCastException을 던질 수 있다. 한편, 안전하다고 검증된 비검사 경고를 그대로 두면, 진짜 문제를 알리는 새로운 경고가 나와도 눈치채지 못할 수 있다. 제거하지 않은 수많은 거짓 경고 속에 새로운 경고가 파묻힐 수 있기 때문이다.

@SuppressWarnings 어노테이션은 개별 지역변수 선언부터 클래스 전체까지 어떤 선언에도 달 수 있다. 하지만 @SuppressWarnings 어노테이션은 항상 가능한 한 좁은 범위에 적용해야 한다. 보통은 변수 선언, 아주 짧은 메서드, 혹은 생성자가 될 것이다. 자칫 심각한 경고를 놓칠 수 있으니 절대로 클래스 전체에 적용해서는 안 된다.
한 줄이 넘는 메서드나 생성자에 달린 @SuppressWarnings 어노테이션을 발견하면 지역변수 선언 쪽으로 옮겨야 한다. 이를 위해 지역변수를 새로 선언해야할 수 있지만, 그만한 값어치가 있다. 다음 예를 보자.

public <T> T[] toArray(T[] a){
	if(a.length < size)
    	return (T[]) Arrays.copyOf(elements, size, a.getClass());
	System.arraycopy(elements, 0, a, 0, size);
    if (a.length > size)
    	a[size]=null;
    return a;
}

위 코드를 컴파일하면 비검사 형변환 경고(unchecked cast)가 발생한다. 어노테이션은 선언에만 달 수 있기 때문에 return문에는 @SuppressWarnings를 다는 게 불가능하다. 그렇다고 메서드에 달면 범위가 넓어지니 좋지 않다. 그 대신 반환값을 담은 지역변수를 선언하고 그 변수에 어노테이션을 달아주면 된다. 다음과 같이 수정하면 된다.

public <T> T[] toArray(T[] a){
	if(a.length < size){
    	@SuppressWarnings("unchecked") (T[]) result = (T[]) Arrays.copyOf(elements, size, a.getClass());
        return result;
	}
	System.arraycopy(elements, 0, a, 0, size);
    if (a.length > size)
    	a[size]=null;
    return a;
}

SuppressWarnings("unchecked") 어노테이션을 사용할 때면 그 경고를 무시해도 안전한 이유를 항상 주석으로 남겨야 한다. 다른 사람이 그 코드를 이해하는 데 도움이 되며, 더 중요하게는, 다름 사림이 그 코드를 잘못 수정하여 타입 안정성을 잃는 상황을 줄여준다. 코드가 안전하다는 근거를 찾으면서 해당 코드가 안전하지 않다는 사실을 발견할 수 있으니 근거를 찾으려고 노력해야 한다.

profile
백엔드

0개의 댓글