`strictNullChecks`: 없음도 실제 상태로 모델링하기

"null과 undefined는 독립된 타입이야. 허용한다고 직접 말하지 않으면 다른 타입에 숨어들지 않아."

무엇이 달라지는가

설정을 끄면 null과 undefined를 모든 타입에 대입할 수 있어서 string이나 User라고 적힌 값이 실제로는 비어 있을 수 있어. 타입과 런타임의 차이가 null 접근 오류를 숨겨.

설정을 켜면 둘은 별도 타입이 되고, 허용하려는 계약에만 string | null처럼 명시적으로 포함해. 타입이 실행 현실을 정직하게 말하게 되는 거야.

수정 방법 네 가지

실제 계약에 맞게 string | null로 넓혀.
사용 전에 x !== null 같은 검사로 좁혀.
컴파일러보다 확실한 근거가 있을 때만 비-null 단언 !을 드물게 써.
가능하면 null 자체가 필요 없는 구조로 리팩터링해.

strictNullChecks는 noImplicitAny 다음으로 영향이 큰 엄격 설정이야. 둘을 함께 켜면 실제 코드의 잠재적 불안전 대부분이 드러나.

Code

strictNullChecks 없이와 함께·typescript

// strictNullChecks 없이 — null 어디에나 숨겨짐.
function getUser(id: number): User {
  return null;             // ✅ 컴파일 — null 이 User 에 assignable
}
const u = getUser(1);
console.log(u.name);        // null 이면 runtime 에 크래시

// strictNullChecks 와 함께:
function getUserSafe(id: number): User | null {
  return null;             // ✅ — return type 이 null 명시 허용
}
const u2 = getUserSafe(1);
// u2.name              // ❌ Object is possibly 'null'
if (u2 !== null) {
  u2.name;               // ✅ User 로 narrow
}

// 또는 optional chaining 사용:
u2?.name;                 // string | undefined — 안전 접근

Exercise

User를 반환한다고 선언한 함수의 한 경로에서 null을 돌려줘. strictNullChecks를 켰을 때 오류가 나는지 보고, 반환 타입이나 실패 처리 중 실제 계약에 맞는 쪽으로 고쳐.

Hint

함수가 null을 반환할 수 있다면 공개 타입도 그 사실을 말해야 해. 엄격 모드 이전 코드의 많은 오류는 이 숨은 불일치에서 시작돼.

무엇이 달라지는가

수정 방법 네 가지

Code

External links

Exercise

Progress

댓글 0