Cách TypeScript kiểm tra toàn diện loại bỏ toàn bộ các loại lỗi

type Status = "idle" | "loading" | "success" | "error";

function renderStatus(status: Status): string {
  switch (status) {
    case "idle":
      return "Waiting...";
    case "loading":
      return "Loading...";
    case "success":
      return "Done.";
    case "error":
      return "Something went wrong.";
    default:
      // The exhaustiveness check
      const _exhaustive: never = status;
      return _exhaustive;
  }
} ```

The assignment `const _exhaustive: never = status` is unreachable by design. If you add a new `Status` member and forget to add a `case` above, TypeScript assigns `"new-status"` to `_exhaustive` and immediately reports:

It does this at compile time. No tests needed for this particular bug category.

## A Real-World Example

<Callout type="code" title="API Response Handler">
```typescript
type ApiResponse<T> =
  | { status: "idle" }
  | { status: "loading" }
  | { status: "success"; data: T }
  | { status: "error"; error: ApiError };

function showResponse<T>(response: ApiResponse<T>) {
  switch (response.status) {
    case "idle":
      return <EmptyState />;
    case "loading":
      return <Spinner />;
    case "success":
      return <DataView data={response.data} />;
    case "error":
      return <ErrorBanner message={response.error.message} />;
    default:
      const _exhaustive: never = response;
      return _exhaustive;
  }
} ```

</Callout>

Mỗi nhánh thu hẹp discriminated union một cách chính xác. Nếu sau này ai đó thêm `"retry"` vào `ApiResponse` nhưng quên thêm một nhánh `case "retry"`, trường hợp `default` sẽ bị lỗi ngay tại dòng đó. Không có bất ngờ nào khi chạy.

## Hàm Trợ Giúp

Nhiều codebase thích một hàm có tên hơn là khai báo biến nội tuyến. Nó dễ đọc và cung cấp một nơi duy nhất để kiểm tra khi có gì đó không ổn:

```typescript
function assertNever(
  x: never,
  message = "Unexpected exhaustive case"
): never {
  throw new Error(`${message}: ${JSON.stringify(x)}`);
} ```

Usage:

```typescript
function processState(state: AppState) {
  switch (state.type) {
    case "init": return init(state);
    case "fetch": return fetchData(state);
    case "render": return render(state);
    default: return assertNever(state, "Unhandled AppState");
  }
} ```

Kiểu trả về của hàm là `never`, vì vậy TypeScript từ chối biên dịch lệnh gọi nếu `state` thực sự không phải là `never`. Sự từ chối đó là tín hiệu lỗi.

## Tại Sao Không Chỉ Là Một Default Ném Lỗi?

Một cách tiếp cận ngây thơ là ném lỗi từ `default` mà không cần kiểm tra `never`:

```typescript
default:
  throw new Error(`Unhandled status: ${status}`);

type AuthEvent =
  | { kind: "login"; username: string }
  | { kind: "logout" }
  | { kind: "token_refresh"; token: string }
  | { kind: "session_expired"; reason: string };

function logAuthEvent(event: AuthEvent) {
  switch (event.kind) {
    case "login":
      console.log(`${event.username} logged in`);
      break;
    case "logout":
      console.log("User logged out");
      break;
    case "token_refresh":
      console.log(`Token refreshed, ends ${event.token.slice(-4)}`);
      break;
    case "session_expired":
      console.log(`Session expired: ${event.reason}`);
      break;
    default:
      const _exhaustive: never = event;
      return _exhaustive;
  }
} ```

Adding `{ kind: "mfa_challenge" }` without a corresponding `case` breaks compilation immediately. This is the behavior you want in security-sensitive code where silently ignoring a case can mean silently bypassing a check.

## Exhaustiveness in `if/else` Chains

```typescript
function getRoleName(role: UserRole): string {
  if (role === "admin") return "Administrator";
  if (role === "editor") return "Content Editor";
  if (role === "viewer") return "Read-only Viewer";
  // Exhaustiveness check at the end
  const _exhaustive: never = role;
  return _exhaustive;
} ```

Mẫu này hoạt động giống hệt trong các chuỗi `if/else`. Nó đọc một cách tự nhiên ở cuối chuỗi như một dấu hiệu "không có gì khác nên đến đây".

## Khả Năng Tương Thích Công Cụ

- TypeScript 5.x (tất cả các phiên bản hiện tại) — kiểm tra gán `never` đã ổn định từ các phiên bản đầu. - Chế độ nghiêm ngặt được khuyến nghị: kiểm tra toàn diện dựa vào trình biên dịch để đảm bảo rằng một nhánh không thể truy cập thực sự là `never`. Nó hoạt động mà không cần chế độ nghiêm ngặt, nhưng tín hiệu yếu hơn trong chế độ `noImplicitAny`-off. - ESLint: quy tắc `@typescript-eslint/switch-exhaustiveness-check` bao gồm hầu hết các trường hợp discriminated-union mà không cần biến `never` thủ công. Ưu tiên quy tắc ESLint khi có sẵn, giữ mẫu thủ công cho các công cụ cũ hơn. - IDEs: VSCode, WebStorm và Zed đều hiển thị sự không khớp nội tuyến tại vị trí gán — không cần bước build.

## Hạn Chế và Các Trường Hợp Đặc Biệt

- Thủ thuật gán `never` không hoạt động trực tiếp bên trong các callback `Map` hoặc biểu thức ternary — hãy ưu tiên một hàm trợ giúp có tên trong các ngữ cảnh đó. - Khi một `switch` bao gồm một union bên trong một mapped type, kiểm tra toàn diện có thể tạo ra các kết quả dương tính giả khi truy cập thuộc tính. Chia kiểm tra thành một hàm riêng biệt để giữ cho thông báo lỗi dễ đọc. - Kiểm tra toàn diện thêm một chi phí nhỏ khi biên dịch đối với các union rất lớn (hơn 100 biến thể). Chỉ đáng kể trong các monorepo có nhiều câu lệnh `switch` như vậy. - Không thay thế các bài kiểm tra cho *lỗi logic* trong một trường hợp — nó chỉ bắt được loại *trường hợp bị thiếu*.

## Nơi Áp Dụng Mẫu Này

Những nơi có hiệu quả cao nhất để kiểm tra toàn diện trong một codebase điển hình:

- **Máy trạng thái** (trạng thái UI, trạng thái xác thực, trạng thái thanh toán) — mọi trạng thái mới phải được xử lý rõ ràng. - **Các trình duyệt AST hoặc trình xử lý sự kiện** — việc thêm một loại nút hoặc sự kiện mới phải tạo ra một nhánh mới hoặc một lỗi lớn. - **Các kiểu union phản hồi API** — các biến thể phản hồi mới phải hiển thị một đường dẫn render mới. - **Các bộ điều phối lệnh con CLI** — việc thêm một lệnh con mới phải thêm một trình xử lý hoặc không biên dịch được.

## Tham Khảo Nhanh

```typescript
// Phiên bản nội tuyến (phổ biến nhất)
function handleStatus(status: Status): string {
  switch (status) {
    case "idle": return "Waiting";
    case "loading": return "Loading...";
    case "success": return "Done";
    case "error": return "Failed";
    default: { const _exhaustive: never = status; return _exhaustive; } }
}

// Phiên bản hàm trợ giúp (sạch hơn cho các switch lớn)
function assertNever(x: never, msg?: string): never {
  throw new Error(msg ?? `Unhandled case: ${JSON.stringify(x)}`);
}

// Với discriminated union
type Tree =
  | { type: "leaf"; color: string }
  | { type: "branch"; children: Tree[] }
  | { type: "fruit"; kind: string };

function describeTree(tree: Tree): string {
  switch (tree.type) {
    case "leaf": return `Leaf: ${tree.color}`;
    case "branch":
      return `Branch with ${tree.children.length} children`;
    case "fruit": return `Fruit: ${tree.kind}`;
    default: return assertNever(tree);
  }
} ```

## Bạn Cũng Có Thể Thích

- [JavaScript to Luau: The Complete Roblox Scripting Cheat Sheet (2026)](/en/blog/javascript-to-luau-roblox-scripting)
- [const vs Immutability in JavaScript: The Binding, Not the Value](/en/blog/const-in-js)
- [How to Get the Correct Y Position of an Element in ChatGPT UI (2026 Guide)](/en/blog/get_position_of_an_element_in_js)
- [Stop Using Promise.race for Fallbacks: The Case for Promise.any and AggregateError](/en/blog/promise-any-aggregate-error)