Platform under construction

Errors & Debugging

Advanced

Error Objects

Error objects carry a name, message, stack and sometimes a cause. They are the data structure of failure.

const error = new TypeError("Expected a string");

console.log(error.name);
console.log(error.message);

Errors & Debugging

An Error object should explain what failed and why.

The base Error type has a message. Runtime errors such as TypeError, RangeError and SyntaxError use specialized names.

The stack trace points to where the error was created or thrown. Stack output differs by browser and runtime, but it is essential for debugging.

Modern Error objects can include a cause, which lets you wrap lower-level failures without losing the original error.

name

The error type name, such as TypeError.

message

Human-readable explanation.

stack

Trace of where the error happened.

cause

Original error when wrapping another error.

Examples

Good debugging code keeps the failure path visible.

Specific error type with useful message

function setScore(score) {
  if (!Number.isFinite(score)) {
    throw new TypeError("score must be a number");
  }

  if (score < 0 || score > 100) {
    throw new RangeError("score must be 0-100");
  }
}

Throwing strings

throw "Something failed";

// This loses normal Error object behavior.

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.

Create Error

Base error with a message.

const error = new Error("Something failed");

TypeError

Use for wrong value type.

throw new TypeError("title must be a string");

RangeError

Use for values outside an allowed range.

throw new RangeError("score must be 0-100");

Cause

Wrap a lower-level failure.

throw new Error("Could not load settings", {
  cause: originalError
});

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.

Throw Error objects

They carry message, name and stack.

Use specific built-in types

TypeError and RangeError communicate intent.

Write actionable messages

Say what was wrong, not just that it failed.

Use cause when wrapping

Keep the original error connected.

Do not expose sensitive details to users

Internal stacks belong in logs, not public messages.

Log enough context

The same message can happen in multiple operations.

Production thinking

Reliable software is built by handling failure deliberately.

Why does this matter?

Error objects are the debugging trail. Better error data means faster repair.

Accessibility

User-facing error text should be clear and safe, while technical detail goes to logs.

Production note

Production error reporting should preserve type, message, stack and context.

SEO note

Server-rendered or build-time errors should fail loudly so broken content is not published silently.

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.

Change TypeError to RangeError.
Add a cause error and inspect error.cause.
Compare throwing a string with throwing an Error.

Practice assignment

Do this before moving to the next topic.

Create one Error.
Create one TypeError.
Create one Error with cause.

HTML + JavaScript CSS

Live preview

Self-check

Before you continue, prove that you understand Error Objects.