`strictNullChecks`

"Null 이 자기 타입. Undefined 도. 너가 허용 안 하면 다른 타입에 몰래 안 들어가."

뭐 바꿔

`strictNullChecks` 없으면 `null` 과 `undefined` 가 모든 타입에 assignable. `string` 변수가 비밀리에 `null` 가질 수. `User` 반환하는 함수가 비밀리에 `null` 반환할 수. Type system 이 'string' 말하는데 현실이 'string-or-null' 말하고, 불일치가 모든 NullPointerException 숨김.

Flag 켜지면 `null` 과 `undefined` 가 자기 타입. 허용하는 어떤 union 에든 명시적으로 포함해야. `string | null` 이 null 받음; `string` 안 받음. Type system 이 마침내 진실 말함.

Fix 의 cascade

Legacy codebase 에 strictNullChecks 켜면 조용히 null 허용한 모든 곳 노출. Fix 가 카테고리:

타입 명시: `string` → `string | null`.
쓰기 전 narrow: `if (x !== null) { ... x 를 string 으로 써 ... }`.
Compiler 보다 잘 알 때 non-null assertion `!` 사용 (아껴서).
Nullability 완전 제거하도록 refactor.

`strictNullChecks` 가 noImplicitAny 다음으로 두 번째로 큰 impact strict flag. 결합, 그 두 flag 가 실제 codebase 의 latent 타입 안전 부족 대부분 잡음.

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

선언된 return 타입이 User 인 함수 써. 어떤 path 에 실제로 null 반환하게. strictNullChecks 끄면 조용히 컴파일. 켜 — 에러 나타나는 거 봐. Return type update 하거나 null case guard 해서 fix.

Hint

Flag 가 정직 강제: 너의 함수가 null 반환 가능하면 타입이 그렇게 말해야. Pre-strict codebase 의 대부분 TypeScript 버그가 이 숨겨진 불일치 추적.

뭐 바꿔

Fix 의 cascade

Code

External links

Exercise

Progress

댓글 0