Common Pitfalls and Real-World Exhaustive Checking
12345678910111213141516171819202122232425// Define possible API response types using a discriminated union type ApiResponse = | { status: "success"; data: string } | { status: "error"; errorCode: number } | { status: "loading" }; // Helper function to enforce exhaustive checking function assertNever(x: never): never { throw new Error("Unexpected object: " + JSON.stringify(x)); } // Handle the API response with exhaustive checking function handleResponse(response: ApiResponse): string { switch (response.status) { case "success": return "Data received: " + response.data; case "error": return "Error code: " + response.errorCode; case "loading": return "Loading..."; default: // If a new status is added and not handled, TypeScript will error here return assertNever(response); } }
When you work with discriminated unions in TypeScript, exhaustive checking ensures that every possible variant is handled in your logic. A common pitfall is forgetting to update switch statements or conditional logic after adding a new variant to a union type. If you omit exhaustive checking, TypeScript will not warn you when a new case is missing, which can lead to subtle bugs—such as unhandled states in UI rendering or missing error processing.
Using the never type and an assertNever helper function, as shown above, protects you from these mistakes. When you add a new variant to your union (for example, { status: "timeout" }), TypeScript will immediately report an error at the assertNever call if you forget to handle it in your switch statement. This pattern makes your code more robust and easier to maintain, especially as your application grows and evolves.
Tack för dina kommentarer!
Fråga AI
Fråga AI
Fråga vad du vill eller prova någon av de föreslagna frågorna för att starta vårt samtal
Awesome!
Completion rate improved to 5.88Common Pitfalls and Real-World Exhaustive Checking
Svep för att visa menyn
12345678910111213141516171819202122232425// Define possible API response types using a discriminated union type ApiResponse = | { status: "success"; data: string } | { status: "error"; errorCode: number } | { status: "loading" }; // Helper function to enforce exhaustive checking function assertNever(x: never): never { throw new Error("Unexpected object: " + JSON.stringify(x)); } // Handle the API response with exhaustive checking function handleResponse(response: ApiResponse): string { switch (response.status) { case "success": return "Data received: " + response.data; case "error": return "Error code: " + response.errorCode; case "loading": return "Loading..."; default: // If a new status is added and not handled, TypeScript will error here return assertNever(response); } }
When you work with discriminated unions in TypeScript, exhaustive checking ensures that every possible variant is handled in your logic. A common pitfall is forgetting to update switch statements or conditional logic after adding a new variant to a union type. If you omit exhaustive checking, TypeScript will not warn you when a new case is missing, which can lead to subtle bugs—such as unhandled states in UI rendering or missing error processing.
Using the never type and an assertNever helper function, as shown above, protects you from these mistakes. When you add a new variant to your union (for example, { status: "timeout" }), TypeScript will immediately report an error at the assertNever call if you forget to handle it in your switch statement. This pattern makes your code more robust and easier to maintain, especially as your application grows and evolves.
Tack för dina kommentarer!
