Null is your firend, not a mistake

로마 엘 리자 로프
Null is your firend, not a mistake
병 심 설
Kotlin Island from Wikimedia by Pavlikhin, CC BY-SA 4.0
저 는 자바 언어 프로 그래 밍 을 사용 한 지 오래 되 었 습 니 다. 자바 를 통 해 대형 소프트웨어 (백만 줄 코드) 를 작성 하고 유지 하 는 데 무엇 을 주의해 야 하 는 지 알 게 되 었 고 업계 전체 가 빈 포인터 이상 NullPointerException（NPE） 을 피 하려 고 노력 하 는 것 을 직접 보 았 습 니 다. 크 고 작은 자바 라 이브 러 리 를 괴 롭 히 고 있 습 니 다.2009 년 발명자 Tony Hoare 가 공 인용 이 그 가 초래 한 '10 억 달러 의 잘못' 이 라 고 인정 하기 전에 사람들 은 이미 그것 의 위험성 을 의식 했다.
1996 년 자바 1.0 이 발 표 됐 을 때 이 문 제 는 그리 뚜렷 하지 않 았 다.전형 적 인 자바 API 의 예 를 살 펴 보 자. File.list() 방법.폴 더 의 내용 을 열거 하 는 데 사 용 됩 니 다. 다음 과 같 습 니 다.

for(String name : new File("directory").list()) {
    System.out.println(name);
}

폴 더 가 존재 할 때 만 위의 코드 가 정상적으로 작 동 합 니 다. 그렇지 않 으 면 던 집 니 다 NPE. list() 가 되 돌 아 왔 기 때 문 입 니 다 null.그런데 누가 이런 코드 를 쓸 수 있 을까요?list() 방법의 문서 에서 폴 더 가 존재 하지 않 을 때 되 돌아 오 는 것 null 을 명확 하 게 설명 할 뿐만 아니 라 현대 의 IDE 도 특정한 코드 에 대해 경 고 를 할 것 이다.
그러나 자바 프로 그래 밍 을 사용 할 때 개발 자 들 은 이런 오 류 를 자주 범 합 니 다.지금까지 그들 이 어떻게 발생 했 는 지 에 대한 많은 연구 가 있 었 다.결과 에 따 르 면 대부분의 경우 우리 의 API 함 수 는 null 로 돌아 가 서 는 안 되 고 다른 개발 자 들 도 null 로 돌아 가 기 를 원 하지 않 는 다.일부 특수 한 상황 에서 예 를 들 어 결 성 된 값, 자바 의 관례 는 '빈 대상' (빈 집합, 채 워 지지 않 은 대상 등) 을 되 돌려 주거 나 이상 을 던 지 는 것 이 null 로 돌아 가 는 것 보다 더 나쁘다.이것 이 바로 디자인 Files.newDirectoryStream, 고급 버 전 File.list, 어떤 경우 에 도 null 이 나타 나 지 않 는 이유 이다.
그래서 null 이 일부 특수 한 상황 에서 함수 로 값 을 되 돌려 줄 때 성능 최적화, 초기 화 되 지 않 은 인용 필드 등 은 항상 당신 을 당황 하 게 하고 처리 할 준비 가 되 어 있 지 않 습 니 다.빈 값 을 처리 해 야 하 는 경우 가 적 을 뿐만 아니 라 자바 에서 빈 값 을 처리 하 는 코드 는 매우 번거롭다.

String[] list = new File("directory").list();
if (list != null) {
    for (String name : list) {
        System.out.println(name);
    }
}

의심 할 여지없이, 당신 의 고객 이 생산 환경 에서 NPE 를 발견 하지 않 으 면, 당신 은 정말 이런 코드 를 쓰 고 싶 지 않다.
null 에 대한 두려움 이 극단 적 인 상황 을 초래 했다.일부 자바 인 코딩 스타일 은 null 을 완전히 금지 하고 개발 자 에 게 가 증 스 러 운 일 을 맡 깁 니 다.이러한 자바 라 이브 러 리 를 본 적 이 있 는 지 모 르 겠 습 니 다. 모든 도 메 인 대상 은 특수 한 Null 인 터 페 이 스 를 실현 하고 수 동 인 코딩 으로 생 성 된 '빈 대상' 인 스 턴 스 를 제공 해 야 합 니 다.못 봤 으 면 다행 이 야.하지만 빈 값 을 피하 기 위해 자바 코드 를 오염 시 키 는 Optional 포장 기 를 보 았 다 고 장담 합 니 다.
일부 집합 프레임 워 크 의 API 는 null 요 소 를 신중하게 금지 하고 일부 자바 핵심 팀 구성원 들 은 자바 집합 프레임 워 크 가 null 에 대한 지원 이 잘못 되 었 다 고 생각 합 니 다.이것 은 사람 을 매우 슬 프 게 한다.
사실 null 이라는 개념 은 잘못된 것 이 아니 지만 자바 의 유형 시스템 은 null 이 모든 유형의 구성원 이 라 고 생각 합 니 다.자바 에서 “abc” 는 합 법 적 인 String 이 고 null 도 합 법 적 인 String 이다.전자 에서 string 의 모든 방법 을 사용 할 수 있 습 니 다. 예 를 들 어 substring.그러나 후자 에서 사용 하면 운행 중 오류 가 발생 할 수 있다.그것 은 유형 이 안전 합 니까?꼭 그런 건 아니 야.한 유형의 특정 값 이 특정한 작업 을 할 때 실 행 될 때 이상 (예 를 들 어 0 제외) 이 발생 하 는 것 은 정상 이지 만 한 값 에 대해 이 유형의 모든 작업 에 이상 이 발생 하면 이 값 이 이 유형 에 속 하지 않 음 을 먼저 나타 낸다.모든 NPE 는 자바 의 유형 시스템 에 뚜렷 한 결함 이 있 음 을 나타 낸다.
더 많은 유형의 안전 한 프로 그래 밍 언어, 예 를 들 어 Kotlin 은 null 의 개념 을 합 리 적 으로 유형 시스템 에 통합 시 켜 이 결함 을 복구 합 니 다.검사 와 경 고 를 추가 하 는 것 도 효과 가 있 지만 부족 하 다.분명 한 것 은 건전 한 유형 시스템 이 String 유형의 모든 변 수 를 지원 하도록 허용 해 야 한다.그래서 Kotlin 에서 null 유형 에 부 여 된 변 수 는 경고 가 아니 라 유형 오류 입 니 다. 마치 수치 String 를 42 유형 변수 에 부여 하 는 것 과 같 습 니 다.
형식 시스템 에서 합 리 적 인 null 지원 은 API 디자인 의 전환점 으로 더 이상 null 을 두려워 할 이유 가 없습니다.일부 함 수 는 비어 있 는 유형 String 을 되 돌려 주 고, 다른 함 수 는 비어 있 지 않 은 유형 String? 을 되 돌려 주 며, 일부 함수 가 돌아 오 는 것 String 과 같 습 니 다.그것들 은 모두 서로 다른 유형 으로 다 르 지만 안전 한 조작 집 을 가지 고 있다.
유형 안전 한 null 로 '부족 한 값' 을 표시 하 는 것 이 더 좋 고 효율 적 이 며 간결 합 니 다.Kotlin 표준 라 이브 러 리 의 String 함 수 를 보 세 요. string 을 숫자 로 바 꾸 는 데 사 용 됩 니 다. 바 꿀 수 없 으 면 null 로 돌아 갑 니 다.사용 하기에 매우 즐 겁 습 니 다. 명령 행 프로그램 을 만 들 고 integer 인 자 를 받 아들 이 며 인자 의 부족 을 처리 하 는 것 은 간단 합 니 다.

fun main(args: Array) {
    val id = args.getOrNull(0)?.toIntOrNull() 
        ?: error("id expected")
    // ...
}

API 디자인 에서 null 을 사용 하 세 요. 당신 과 Kotlin 의 좋 은 친구 입 니 다.그것 을 두려워 할 이유 도, Int 모드 나 포장 기 를 사용 해서 그것 을 처리 할 이유 도, 이상 하 다 고 말 할 필요 도 없다.API 에서 null 을 합 리 적 으로 사용 하면 더 읽 을 수 있 고 안전 한 코드 를 가 져 다 주 며 모델 코드 를 멀리 할 수 있 습 니 다.
깊이 읽다
이 주 제 를 좋아 하고 언어 디자인 에 대한 세부 사항 을 더 알 고 싶다 면 이 글 을 읽 는 것 을 고려 해 보 세 요. Dealing with absence of value.
글 의 첫 번 째 위 챗 공식 번호:String.toIntOrNull() 자바, 안 드 로 이 드 오리지널 지식 공유, LeetCode 문제 풀이 에 전념 합 니 다.
더 많은 최신 오리지널 글, 스 캔 나 를 주목 하 라!