Platform under construction

Errors & Debugging

Advanced

Custom Errors

Custom errors let an application name its own failure types and attach useful metadata.

class ValidationError extends Error {
  name = "ValidationError";
}

throw new ValidationError("Title is required");

Errors & Debugging

A custom error gives application failures a clear type.

A custom error usually extends Error and sets a distinct name. That lets catch blocks distinguish validation errors from network errors or programmer mistakes.

Custom errors can include fields such as code, field or details. Keep them small and predictable.

Use custom errors for repeated, meaningful failure categories. Do not create a new class for every one-off message.

extends Error

Builds on normal Error behavior.

name

Identifies the custom error type.

metadata

Extra safe fields such as code or field.

instanceof

Checks whether an error is a specific custom type.

Examples

Good debugging code keeps the failure path visible.

Known error handled locally

try {
  saveRecord(input);
} catch (error) {
  if (error instanceof ValidationError) {
    output.textContent = error.message;
  } else {
    throw error;
  }
}

One catch treats every error as user input

try {
  saveRecord(input);
} catch (error) {
  output.textContent = error.message;
}

// Programmer bugs now look like normal validation.

Code patterns

Reusable examples for quick reference.

These examples focus on the debugging patterns you will reuse: safe parsing, throwing, custom error types, console inspection, breakpoints and async failure handling.

Basic custom error

Extend Error and set a name.

class ValidationError extends Error {
  name = "ValidationError";
}

Custom metadata

Add safe structured detail.

class ValidationError extends Error {
  constructor(message, field) {
    super(message);
    this.name = "ValidationError";
    this.field = field;
  }
}

instanceof check

Handle known custom errors differently.

if (error instanceof ValidationError) {
  showMessage(error.message);
} else {
  throw error;
}

Error code

Codes are useful for translation or UI mapping.

throw new ValidationError("Required value missing", "title");

Rules that matter

Make failures observable and recoverable where possible.

Debugging starts before something breaks. Clear error types, helpful messages and visible failure states make the code easier to repair.

Extend Error

Keep normal error behavior.

Set a clear name

The name should describe the failure category.

Use metadata carefully

Attach safe fields such as code or field.

Use instanceof for known handling

Then rethrow unknown errors.

Avoid too many custom classes

Use them for stable categories.

Keep messages safe

Do not expose secrets or internal details to users.

Production thinking

Reliable software is built by handling failure deliberately.

Why does this matter?

Custom errors let code handle expected application failures without hiding unexpected bugs.

Accessibility

Validation errors can map to clear field messages and status text.

Production note

Production systems can report custom error names and codes for better monitoring.

SEO note

Build and render errors should identify failure categories clearly during publishing workflows.

Live code lab

Change the HTML, CSS or JavaScript and run the result.

The preview runs inside an isolated iframe. The JavaScript is placed inside the HTML editor for now, so every example stays together and remains easy to understand.

Mini assignment

Try this now.

Add a code property to ValidationError.
Show the field name in the output.
Rethrow unknown errors instead of showing a generic message.

Practice assignment

Do this before moving to the next topic.

Create one class that extends Error.
Throw the custom error.
Handle it with instanceof.

HTML + JavaScript CSS

Live preview

Self-check

Before you continue, prove that you understand Custom Errors.