TypeScript `@throws` JSDoc and Error Typing in 2026: Why Exceptions Are Still Untyped and What to Do About It

7.8 relevance

Deep dive into TypeScript's untyped exceptions with practical patterns for production — directly actionable for any TypeScript engineer.

Languages dev.to

Answer the board on AI readiness

Arrive with evidence, not opinion. See how your foundation benchmarks against your peers, get a clear read, and leave with a ranked place to start.

Why It Matters

For platform and data engineers building reliable TypeScript services, the absence of typed exceptions means runtime crashes from unhandled errors slip past static analysis, forcing you to choose between verbose Result types or fragile manual documentation patterns.

Key Takeaways

Adopt Result types or discriminated unions with `instanceof` guards in your TypeScript codebase now to get compiler-verified error handling instead of relying on unenforced `@throws` JSDoc annotations.

TypeScript `@throws` JSDoc and Error Typing in 2026: Why Exceptions Are Still Untyped and What to Do About It

Summary

TypeScript in 2026 still lacks typed exceptions because it inherits JavaScript's unchecked exception model, leaving `@throws` JSDoc annotations with zero compiler enforcement. Three technical barriers prevent implementation: dynamic function references lose throw information through indirection, npm packages lack throw annotations, and JavaScript's `throw` accepts any type. Teams must adopt Result types (`Result<T, E>`) or discriminated unions with type guards to get compiler-verified error handling today.

Author

jsmanifest