validating-type-assertions

Type assertions bypass runtime checks, while type guards validate data at runtime. Use type guards for external data from APIs, JSON, or user input; use assertions only for data you've already validated or fully control. Type guards ensure safety; assertions risk runtime errors if assumptions fail.

Apply runtime validation with a schema parser before asserting the type. Extract and validate each field explicitly, then assert only after confirming the data structure matches your expected type. This prevents unsafe casting of malformed external data.

The 'as' keyword asserts a type without runtime checks; type guards validate data conditionally at runtime. For unknown data, type guards are safer because they verify the actual shape before narrowing the type, while 'as' assertions assume correctness without proof.

Validate external input explicitly using schema parsing or conditional checks before asserting its type. Check field existence, value types, and constraints at runtime, then apply the assertion only after validation passes. This prevents crashes from unexpected data shapes.

No. Type assertions on unvalidated data create runtime safety risks because the assertion doesn't check if data actually matches the expected type. Always validate user input with a type guard or schema parser first, then assert if validation succeeds.

Avoid casting external data without validation, chaining multiple assertions without proof, and using assertions to silence type errors instead of fixing the underlying type mismatch. These patterns hide bugs; use explicit validation and type guards instead.