Error Handling, Safety & Strict Mode

Question 1

What is TypeScript’s strict mode?

Answer 1

Strict mode enables a set of type-checking options that enforce stricter rules, improving safety and reducing bugs.

Question 2

What does ‘strict’ in tsconfig.json enable?

Answer 2

It enables all strict type-checking options like strictNullChecks, noImplicitAny, etc.

Question 3

What is the non-null assertion operator in TypeScript?

Answer 3

It’s an exclamation mark (!) used after a variable to assert that it’s not null or undefined.

Question 4

When should you use the non-null assertion operator?

Answer 4

Use it when you’re absolutely certain a value is not null or undefined, but TypeScript cannot infer it.

Question 5

What are type guards in TypeScript?

Answer 5

They are techniques to narrow the type of a variable within a conditional block using typeof, instanceof, or custom checks.

Question 6

How do you create a custom type guard?

Answer 6

Use a function that returns ‘x is SomeType’ and performs necessary runtime checks.

Question 7

What is the ‘typeof’ type guard?

Answer 7

It’s used to narrow primitive types like number, string, boolean: e.g., typeof x === ‘string’.

Question 8

What is the ‘instanceof’ type guard?

Answer 8

It’s used to check if an object is an instance of a class or constructor function.

Question 9

What is exhaustiveness checking?

Answer 9

It ensures all possible cases in a union type are handled, typically in a switch statement using the never type.

Question 10

How do you implement exhaustiveness checking in TypeScript?

Answer 10

Use a switch statement and a default case that assigns to a variable of type ‘never’ to catch unhandled cases.

Question 11

What is the difference between ‘unknown’ and ‘any’?

Answer 11

‘unknown’ is safer; you must narrow its type before usage, whereas ‘any’ disables type checking altogether.

Question 12

What’s an advantage of ‘unknown’ over ‘any’?

Answer 12

‘unknown’ enforces explicit type checks, promoting safer code.

Question 13

What is a disadvantage of strict mode?

Answer 13

It may increase verbosity and development time, especially in large legacy codebases.

Question 14

What is a potential drawback of the non-null assertion operator?

Answer 14

It can lead to runtime errors if the value is actually null or undefined.

Question 15

What is a best practice for custom type guards?

Answer 15

Keep them simple, specific, and colocated with the types they guard.

Question 16

What is a best practice when using ‘unknown’?

Answer 16

Always use type guards to narrow it before using the value.

Question 17

What are use cases for exhaustiveness checking?

Answer 17

State machines, Redux reducers, and discriminated union types where all variants must be handled.

Question 18

What is the impact of strict mode on system design?

Answer 18

It promotes cleaner, more predictable code and surfaces hidden assumptions early in development.

Question 19

How does ‘unknown’ affect architectural decisions?

Answer 19

It encourages defensive programming and explicit type validation at boundaries (e.g., API input).

Question 20

How does strict mode improve fault tolerance?

Answer 20

By catching potential null/undefined issues and type mismatches at compile-time before they reach production.

Question 21

How do these features help with debugging?

Answer 21

They reduce ambiguous runtime behavior by surfacing issues during development, making bugs easier to track.

Question 22

What is a real-world tradeoff with strict null checks?

Answer 22

You might have to rewrite or over-annotate legacy code to satisfy the compiler.

Question 23

What is a common interview question about TypeScript safety?

Answer 23

What is the difference between ‘any’ and ‘unknown’ and when would you use each?

Question 24

What is a gotcha with ‘instanceof’ type guard?

Answer 24

It doesn’t work reliably across execution contexts (e.g., iframes) and won’t work on interfaces.

Question 25

What is a common mistake with the non-null assertion operator?

Answer 25

Using it too liberally and bypassing TypeScript’s safety checks, leading to runtime errors.

Question 26

What is an example of exhaustiveness checking in action?

Answer 26

Using a switch on a discriminated union and ensuring the default case throws if a case is unhandled.

Question 27

What architectural benefit do type guards provide?

Answer 27

They allow for more flexible but safe handling of polymorphic data, supporting open/closed design.

Question 28

How do type guards impact performance?

Answer 28

They have minimal runtime cost and primarily affect compile-time safety and code clarity.

Question 29

What is a best practice for handling 'any'?

Answer 29

Avoid it unless necessary, and prefer narrowing or using unknown with guards instead.

Question 30

What is a performance implication of strict mode?

Answer 30

There is no runtime performance impact—it's purely a compile-time feature.

Question 31

How can strict mode help with API integrations?

Answer 31

It forces you to handle missing or malformed data explicitly, reducing the chance of runtime failures.

Question 32

What is a benefit of combining unknown and type guards?

Answer 32

You get both flexibility (handling any input) and safety (ensuring it's valid before using it).

Question 33

What is a monitoring benefit of exhaustiveness checking?

Answer 33

If a new case is added to a union and not handled, the compiler can catch it before it leads to silent errors.

Question 34

How can you enforce exhaustiveness without a switch?

Answer 34

Using if-else chains with assertNever functions to throw for unhandled cases.

Question 35

What's a potential gotcha with strict mode in legacy code?

Answer 35

It may cause hundreds of errors when first enabled, requiring significant refactoring.

Question 36

How can you enforce safer null handling without non-null assertions?

Answer 36

Use optional chaining, nullish coalescing, or proper type narrowing instead.

Question 37

What is a real-world example where 'unknown' is preferred?

Answer 37

Handling user input from external sources like JSON.parse or API responses.

Question 38

What happens if you forget to handle a case in exhaustiveness checking?

Answer 38

The compiler will throw an error if you use a 'never' type check to enforce it.

Question 39

What should you watch for when using 'any' in third-party libraries?

Answer 39

They might hide bugs if the types are too permissive or outdated.