# JavaScript throw Errors: Throwing Exceptions and Custom Errors

Source: https://devdocs10.com/articles/javascript/js-throw  
By Murat Bo · Published 2026-07-03 · DevDocs10 (https://devdocs10.com)

The `throw` statement lets JavaScript stop normal execution and raise an exception that can be handled by `try...catch`. It is the standard way to report failures, reject invalid input, and signal exceptional conditions in your own code.

> **Quick answer:** Use `throw` when a function cannot continue safely or when you want to signal an error condition immediately. Most code throws an `Error` object or a subclass like `TypeError`, then catches it with `try...catch` when recovery is possible.

> **Difficulty:** Beginner
>
> **You’ll understand this better if you know:** basic functions, conditional logic, and how `try...catch` handles errors in JavaScript.

## 1. What Is throw Errors?

In JavaScript, `throw` interrupts the current execution flow and sends an exception up the call stack. If nothing catches that exception, the program or the current task fails.

- It is used to report invalid states, bad input, or unrecoverable problems.
- It works with any value, but using an `Error` object is the normal and recommended approach.
- It pairs with `try...catch` for handling failures.
- It can be used in synchronous code and inside functions called by asynchronous code, but it is not the same as rejecting a Promise.

Think of `throw` as saying, “Stop here; this operation cannot continue correctly.”

## 2. Why throw Matters

Without `throw`, invalid data can continue moving through your program and create harder-to-debug bugs later. Throwing early makes problems visible at the point where they happen.

It matters because it helps you:

- fail fast when input is wrong
- separate normal results from exceptional failures
- give callers a clear reason for a problem
- avoid silent corruption of data or state

You should not use `throw` for normal branching logic. If a missing value or alternate path is expected, return a value like `null`, `undefined`, or a status object instead.

## 3. Basic Syntax

### The simplest form

JavaScript accepts any expression after `throw`, but an `Error` object is the best default choice because it includes a message and stack trace.

```javascript
throw new Error("Something went wrong");
```

This stops execution immediately unless a surrounding `try...catch` block handles it.

### How try...catch fits in

Use `try` for code that might fail and `catch` for handling the exception.

```javascript
try {
  throw new Error("File not found");
} catch (error) {
  console.log(error.message);
}
```

Output (tested with Node 24.21.0):

```text
File not found
```

The `catch` block receives the thrown value, and the program can continue after handling it.

## 4. Step-by-Step Examples

### Example 1: Rejecting invalid input

When a function requires a valid number, throwing an error prevents incorrect values from being used later.

```javascript
function calculateTax(amount) {
  if (typeof amount !== "number") {
    throw new TypeError("amount must be a number");
  }

  return amount * 0.2;
}

console.log(calculateTax(100));
```

Output (tested with Node 24.21.0):

```text
20
```

This example throws a `TypeError` when the argument has the wrong type, which makes the failure explicit.

### Example 2: Stopping a function when a required value is missing

If a required setting or object property is missing, throwing prevents a later crash in a less obvious place.

```javascript
function sendWelcomeEmail(user) {
  if (!user || !user.email) {
    throw new Error("User email is required");
  }

  return `Sending welcome email to ${user.email}`;
}
```

This pattern is common in validation code because it keeps the rest of the function simple and safe.

### Example 3: Rethrowing after adding context

Sometimes you want to catch an error, add context, and then throw a new one or rethrow the original error.

```javascript
function loadSettings() {
  try {
    throw new Error("Could not read settings file");
  } catch (error) {
    throw new Error(`Settings load failed: ${error.message}`);
  }
}
```

Re-throwing is useful when lower-level code knows the cause, but higher-level code needs a clearer message.

### Example 4: Throwing from browser event logic

In browser code, you can throw inside an event handler or helper function when a required DOM element is missing.

```javascript
function updateStatus() {
  const status = document.querySelector("#status");

  if (!status) {
    throw new Error("Status element not found");
  }

  status.textContent = "Ready";
}
```

This protects your code from silently failing when the page structure is different from what the script expects.

## 5. Practical Use Cases

- Validating function arguments before doing work
- Rejecting impossible states in application logic
- Reporting missing configuration values
- Failing fast in library code when the API is used incorrectly
- Guarding DOM access when an element must exist

These are cases where continuing would either produce incorrect results or make debugging much harder.

## 6. Common Mistakes

### Mistake 1: Throwing a string instead of an Error object

JavaScript technically allows any value to be thrown, but a plain string does not include the same useful debugging information as an `Error` object.

**Problem:** This works, but it produces poorer diagnostics and makes error handling less consistent.

```javascript
throw "Invalid input";
```

**Fix:** Throw an `Error` or a specific subclass.

```javascript
throw new Error("Invalid input");
```

The corrected version gives you a message and a stack trace, which are far more useful when debugging.

### Mistake 2: Forgetting that throw stops execution

Code after a `throw` statement does not run unless the error is caught elsewhere. Beginners sometimes expect the function to keep going.

**Problem:** The line after `throw` is unreachable, so it will never run.

```javascript
function checkAge(age) {
  if (age < 18) {
    throw new Error("Too young");
    return "Denied";
  }

  return "Allowed";
}
```

**Fix:** Put the return inside a normal branch, or let the exception be the only exit from the failure path.

```javascript
function checkAge(age) {
  if (age < 18) {
    throw new Error("Too young");
  }

  return "Allowed";
}
```

The fixed version works because the failure path ends at the exception, and the success path returns normally.

### Mistake 3: Throwing inside a context that expects a Promise rejection

In asynchronous code, throwing inside a Promise executor or an `async` function has different effects than returning a rejected Promise. If you want callers to use `await` or `catch`, you need to understand the boundary.

**Problem:** A plain throw inside an `async` function becomes a rejected Promise, but throwing outside a Promise chain may crash the current call stack instead of being handled where you expect.

```javascript
async function loadProfile() {
  throw new Error("Profile unavailable");
}
```

**Fix:** Use `try...catch` where you await the function, or return a rejected Promise explicitly when that better matches the API design.

```javascript
async function loadProfile() {
  return Promise.reject(new Error("Profile unavailable"));
}

async function main() {
  try {
    await loadProfile();
  } catch (error) {
    console.log(error.message);
  }
}
```

The corrected version makes the error handling path explicit for promise-based code.

## 7. Best Practices

### Use specific error types when they communicate more clearly

Choose subclasses like `TypeError`, `RangeError`, or `SyntaxError` when they describe the problem better than a generic error.

```javascript
function setAge(age) {
  if (age < 0) {
    throw new RangeError("age must be 0 or greater");
  }
}
```

Specific error types make debugging and filtering easier.

### Keep error messages actionable

A good message tells the caller what went wrong and, when helpful, what was expected.

```javascript
throw new Error("Email is required to create a user account");
```

Clear messages reduce guesswork and save time during debugging.

### Throw early, close to the source of the problem

Validation should happen before a function does meaningful work. That keeps failures localized.

```javascript
function parsePort(value) {
  if (value === undefined) {
    throw new Error("Port is required");
  }

  return Number(value);
}
```

Failing early avoids partial work and reduces the chance of corrupt state.

## 8. Limitations and Edge Cases

- `throw` only works as intended when the exception is inside a reachable execution path; code after it does not run.
- Throwing in asynchronous code is not the same as handling a Promise rejection unless the code is inside an `async` function or a Promise chain.
- If you throw a non-`Error` value, some tooling may display weaker diagnostics or miss useful stack information.
- Errors thrown in event handlers can appear in the browser console, but they do not automatically stop other unrelated code from running.
- Libraries may catch and wrap your error, so the final message seen by the caller may differ from the original one.

One common “not working” complaint is that an error seems to disappear in an `async` function. In practice, the error becomes a rejected Promise, so the caller must use `await` with `try...catch` or attach a rejection handler.

## 9. Practical Mini Project

Let’s build a tiny validation helper for a signup form. The helper throws when the input is invalid, and the caller decides how to display the message.

```javascript
function validateSignup(name, email) {
  if (!name || name.trim() === "") {
    throw new Error("Name is required");
  }

  if (!email || !email.includes("@")) {
    throw new Error("Valid email is required");
  }

  return true;
}

function submitSignup() {
  try {
    validateSignup("Ava", "ava@example.com");
    console.log("Signup data is valid");
  } catch (error) {
    console.log(`Form error: ${error.message}`);
  }
}

submitSignup();
```

Output (tested with Node 24.21.0):

```text
Signup data is valid
```

This small example shows the full pattern: validate, throw on invalid data, catch at a higher level, and report a user-friendly message.

## 10. Key Points

- `throw` stops normal execution and raises an exception.
- Prefer `Error` objects over strings or other primitive values.
- Use `try...catch` when you can recover or want to show a controlled message.
- Throw early when input is invalid or the state is impossible.
- Use specific error types and clear messages whenever possible.

## 11. Practice Exercise

- Write a function called `parseUsername` that accepts a string.
- Throw an error if the value is missing, not a string, or shorter than 3 characters.
- Return the trimmed username when the value is valid.

**Expected output:** `parseUsername(" sam ")` should return `"sam"`, while invalid input should throw a helpful error.

**Hint:** Check the type first, then trim the string, then test its length.

```javascript
function parseUsername(value) {
  if (typeof value !== "string") {
    throw new TypeError("Username must be a string");
  }

  const trimmed = value.trim();

  if (trimmed.length < 3) {
    throw new RangeError("Username must be at least 3 characters long");
  }

  return trimmed;
}

console.log(parseUsername("  sam  "));
```

Output (tested with Node 24.21.0):

```text
sam
```

## 12. Final Summary

The `throw` statement is JavaScript’s standard way to signal exceptional failure. It immediately stops normal execution and passes an error to the nearest matching `try...catch` block, or to the runtime if nothing catches it.

In real code, `throw` is most useful for validation, impossible states, and clear failure reporting. Use an `Error` object or subclass, keep the message specific, and catch the exception only where recovery or user-facing handling makes sense.

As you continue, practice deciding between `throw` and a normal return value. That habit will help you write JavaScript that fails loudly when it should and stays easy to debug.