Suggest an edit

Improve this article

Refine the answer for “Runtime errors and TS”. Your changes go to moderation before they’re published.

Approval required

Content

What you’re changing

Title (EN)

Short answer (EN)

Shown above the full answer for quick recall.

Answer (EN)

## 1. Why does TypeScript prevent **runtime errors**

> Because TypeScript checks types **at compile time**,
> that is, **before the code runs**.

It analyzes the code, finds potential errors, and will not let the project build if something "does not match by type".

Example:

```javascript
function square(num: number) {
  return num * num;
}

square("4"); // Compilation error
```

In JavaScript this code would fail **at runtime**,
while TypeScript stops the error **at build time (compile-time)**.

> That is why they say TypeScript "shifts errors left" -
> from production -> into the compiler.

---

## 2. Why TypeScript **does not guarantee 100% error-free code**

TypeScript is a **compile-time type-checking tool**,
but **it does not execute code**, and therefore:

- it does not see real data at runtime;
- it does not know what will come from an API, a database, or user input;
- it does not control side effects, logic, or environment errors.

Example:

```javascript
function getUserName(): string {
  return JSON.parse('{"name":123}').name; // TS thinks this is a string
}
```

> The compiler is sure a string will be returned
> But at runtime it is a number, and `.toUpperCase()` will then throw an error

```javascript
getUserName().toUpperCase(); // Runtime error
```

**TypeScript checks the structure of the code, not the content of the data.**

---

## 3. Why TypeScript **does not check types at runtime**

Because after compilation TypeScript **disappears completely**.
It **strips out all type information**, leaving plain JavaScript.

Example:

```javascript
// Source code
function greet(name: string) {
  console.log("Hello, " + name);
}

// After compiling to JS:
function greet(name) {
  console.log("Hello, " + name);
}
```

> At runtime (in the browser or in Node.js) **there are no types left at all**.
> The JavaScript engine does not know that `name` should be a `string`.

TypeScript was originally designed as:

> a tool **for developers**, not for executing code.
>
> Its goal is to **warn**, not to **protect at runtime**.

---

## 4. Can you check types at runtime?

TypeScript itself **does not do this**,
but you can add **runtime validation** manually or through libraries:

### Example libraries:

- `zod`
- `io-ts`
- `runtypes`
- `valibot`

Example with **Zod**:

```javascript
import { z } from "zod";

const UserSchema = z.object({
  name: z.string(),
  age: z.number(),
});

const data = JSON.parse('{"name":123, "age":"15"}');

const result = UserSchema.safeParse(data);

if (!result.success) {
  console.error("Type error:", result.error.issues);
}
```

> This way you can **supplement static typing with dynamic validation**,
> if you need one hundred percent protection from errors.

---

## 5. Summing up

| Question | Answer |
|---|---|
| **Why does TS prevent runtime errors?** | Because it **analyzes types before execution**, catching errors at compile time. |
| **Why does TS not guarantee 100% error-free code?** | Because it **does not know the real data** at runtime and **does not execute code**. |
| **Why does TS not check types at runtime?** | Because **all types are removed during compilation** - only plain JavaScript remains. |

---

## Key idea

> TypeScript is a **developer's shield**, not the **application's armor**.
> It prevents *predictable code errors*,
> but does not replace *runtime data validation*.

Markdown · drag & drop images · ⌘B / ⌘I shortcuts527 words

For the reviewer

Note to the moderator (optional)

Visible only to the moderator. Helps review go faster.