Custom error classes in Express - Deep Dive

Overview - Custom error classes

What is it?

Custom error classes are special types of errors you create to represent specific problems in your Express app. Instead of using generic errors, you define your own error types with clear names and extra details. This helps your app handle errors more clearly and respond properly to different problems.

Why it matters

Without custom error classes, all errors look the same and it’s hard to tell what went wrong or how to fix it. This can make your app confusing and unreliable for users. Custom errors let you give meaningful messages and status codes, improving debugging and user experience.

Where it fits

Before learning custom error classes, you should understand basic JavaScript errors and how Express handles errors with middleware. After this, you can learn advanced error handling patterns and how to integrate logging or monitoring tools.

Mental Model

Core Idea

A custom error class is a named container for a specific problem that carries extra information to help your app respond correctly.

Think of it like...

Imagine a mailroom sorting letters. Generic errors are like unlabeled envelopes — you don’t know what’s inside. Custom error classes are like envelopes with clear labels telling you if it’s a bill, invitation, or complaint, so you know exactly how to handle each one.

┌─────────────────────┐
│    Error Base Class  │
├─────────────────────┤
│  message            │
│  stack trace        │
└─────────┬───────────┘
          │
 ┌────────┴─────────┐
 │ CustomErrorClass  │
 ├──────────────────┤
 │  statusCode      │
 │  errorType       │
 └──────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding JavaScript Error Basics

Concept: Learn what a standard JavaScript Error is and how it works.

In JavaScript, an Error is an object that holds a message and a stack trace showing where the error happened. You create one with `new Error('message')`. Express uses these errors to know when something went wrong.

Result

You can create and throw errors with messages that help identify problems.

Understanding the basic Error object is essential because custom errors build on this foundation.

2

Foundation

How Express Handles Errors

Concept: Express uses special middleware to catch errors and send responses.

Express looks for middleware functions with four arguments `(err, req, res, next)`. When you call `next(error)`, Express passes the error to this middleware. This lets you centralize error handling in one place.

Result

Errors thrown or passed to `next()` reach your error handler middleware.

Knowing Express error middleware lets you see where custom errors fit in the request flow.

3

Intermediate

Creating a Basic Custom Error Class

🤔Before reading on: do you think a custom error class must extend Error or can it be a plain object? Commit to your answer.

Concept: Custom error classes extend the built-in Error to add properties like status codes.

You create a class that extends `Error`, call `super(message)` to set the message, and add properties like `statusCode`. For example: class NotFoundError extends Error { constructor(message) { super(message); this.statusCode = 404; this.name = 'NotFoundError'; } }

Result

You get an error object that behaves like Error but also carries HTTP status info.

Extending Error preserves the error’s behavior while letting you add useful details for your app.

4

Intermediate

Using Custom Errors in Express Routes

🤔Before reading on: do you think throwing a custom error inside a route automatically sends a response? Commit to your answer.

Concept: Throw or pass custom errors in routes and handle them in error middleware.

Inside a route, you can throw `throw new NotFoundError('User not found')` or pass it to `next()`. Your error middleware checks the error type and sends the right HTTP status and message: app.use((err, req, res, next) => { if (err.statusCode) { res.status(err.statusCode).json({ error: err.message }); } else { res.status(500).json({ error: 'Internal Server Error' }); } });

Result

Clients get clear error responses matching the problem type.

Using custom errors with middleware separates error detection from response logic, making code cleaner.

5

Intermediate

Adding Extra Data to Custom Errors

Concept: Custom errors can carry more than message and status, like error codes or details.

You can add properties like `errorCode` or `details` to your custom error class: class ValidationError extends Error { constructor(message, details) { super(message); this.statusCode = 400; this.name = 'ValidationError'; this.details = details; // extra info about validation } }

Result

Your error objects provide richer info for clients or logs.

Extra data in errors helps clients understand what went wrong and aids debugging.

6

Advanced

Stack Trace and Error Name Preservation

🤔Before reading on: do you think custom errors automatically have correct stack traces and names? Commit to your answer.

Concept: Properly setting the error name and capturing stack trace is important for debugging.

In custom error constructors, set `this.name` to the class name. Also, call `Error.captureStackTrace(this, this.constructor)` to get a clean stack trace without the constructor call. This helps tools and logs show accurate info.

Result

Errors show correct names and stack traces pointing to the real error source.

Maintaining stack trace and name clarity prevents confusion when debugging complex apps.

7

Expert

Extending Custom Errors for Hierarchies

🤔Before reading on: do you think all custom errors should be independent classes or can they inherit from each other? Commit to your answer.

Concept: You can create error class hierarchies to group related errors and share behavior.

For example, create a base `HttpError` class with status code, then extend it: class HttpError extends Error { constructor(message, statusCode) { super(message); this.statusCode = statusCode; this.name = this.constructor.name; Error.captureStackTrace(this, this.constructor); } } class NotFoundError extends HttpError { constructor(message = 'Not Found') { super(message, 404); } } class UnauthorizedError extends HttpError { constructor(message = 'Unauthorized') { super(message, 401); } }

Result

You get organized error types that simplify handling and extendability.

Hierarchies reduce repetition and make your error system scalable and maintainable.

Under the Hood

Custom error classes work by creating objects that inherit from the built-in Error prototype. This inheritance chain ensures that the error behaves like a normal error, including stack traces and message properties. When you throw or pass these errors in Express, the framework detects them as errors and routes them to error-handling middleware. The extra properties you add, like statusCode, are just normal object properties that your middleware reads to decide how to respond.

Why designed this way?

JavaScript’s Error class was designed to provide basic error info, but it’s generic. Custom error classes were introduced to let developers add context and meaning to errors without losing the built-in error features. Express leverages this by allowing any error object to be passed to middleware, so developers can define rich error types that fit their app’s needs. This design balances flexibility with standard error handling.

┌───────────────┐
│  Your Code    │
│  (throws)     │
└──────┬────────┘
       │
┌──────▼────────┐
│ Custom Error  │
│ Class Object  │
└──────┬────────┘
       │ inherits
┌──────▼────────┐
│  Error Class  │
│  (built-in)   │
└──────┬────────┘
       │
┌──────▼────────┐
│ Express Error │
│ Middleware   │
└──────┬────────┘
       │
┌──────▼────────┐
│ HTTP Response │
│  Sent to User │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think a custom error class must always have a statusCode property? Commit to yes or no.

Common Belief: Custom error classes always need a statusCode property to work properly in Express.

Reality: While statusCode is common, it’s not required. You can create custom errors without it, but your error handler must know how to handle them. The key is consistent handling, not mandatory properties.

Why it matters: Assuming statusCode is mandatory can lead to errors being mishandled or defaulting to 500 without clear reason.

Quick: Do you think throwing a custom error inside an async route automatically sends a response? Commit to yes or no.

Common Belief: Throwing a custom error inside an async route automatically sends the error response to the client.

Reality: In async routes, you must catch errors or pass them to next(). Otherwise, Express won’t catch them automatically, and the request may hang or crash.

Why it matters: Misunderstanding this causes silent failures or unhandled promise rejections in production.

Quick: Do you think custom errors change how JavaScript’s stack trace works? Commit to yes or no.

Common Belief: Custom error classes automatically improve or change the stack trace format.

Reality: Custom errors inherit the stack trace behavior from Error, but you must explicitly capture the stack trace in constructors for best results.

Why it matters: Ignoring stack trace capture leads to confusing or incomplete debugging info.

Quick: Do you think all errors in Express must be instances of Error? Commit to yes or no.

Common Belief: Only instances of Error can be handled by Express error middleware.

Reality: Express treats any object passed to next() as an error, but non-Error objects lack stack traces and standard properties, making debugging harder.

Why it matters: Using plain objects as errors can cause inconsistent error handling and obscure bugs.

Expert Zone

1

Custom error classes can be extended with methods to format error responses dynamically based on environment (dev vs prod).

2

Stack trace capturing with Error.captureStackTrace is V8-specific; other engines may behave differently, so cross-platform apps should test error behavior.

3

Using error class hierarchies allows middleware to catch broad categories of errors by checking instanceof base classes, simplifying error handling logic.

When NOT to use

Custom error classes are less useful for very simple apps or scripts where generic errors suffice. For complex validation, consider libraries like Joi or Zod that provide structured error objects. Also, avoid overusing custom errors for control flow; use them only for exceptional cases.

Production Patterns

In production Express apps, custom errors are used with centralized error middleware that logs errors, sends sanitized messages to clients, and integrates with monitoring tools like Sentry. Hierarchical error classes help map errors to HTTP status codes and user-friendly messages consistently.

Connections

Exception Handling in Java

Similar pattern of creating custom exception classes to represent specific error conditions.

Understanding custom errors in Express helps grasp how typed exceptions work in strongly typed languages, improving cross-language error handling skills.

HTTP Status Codes

Custom error classes often carry HTTP status codes to map errors to proper HTTP responses.

Knowing HTTP status codes deeply helps design meaningful custom errors that communicate the right problem to clients.

Medical Diagnosis

Both involve categorizing problems into specific types to decide the right treatment or response.

Seeing errors as diagnoses helps appreciate why precise error types improve problem-solving and user care.

Common Pitfalls

#1 Throwing a custom error in an async route without catching or passing to next()

Wrong approach:

app.get('/user', async (req, res) => {
throw new NotFoundError('User missing');
});

Correct approach:

app.get('/user', async (req, res, next) => {
try {
throw new NotFoundError('User missing');
} catch (err) {
next(err);
}
});

Root cause:

Express does not automatically catch errors thrown in async functions; they must be caught and passed to next() explicitly.

#2 Not setting the error name in custom error classes

Wrong approach:

class MyError extends Error {
constructor(message) {
super(message);
}
}

Correct approach:

class MyError extends Error {
constructor(message) {
super(message);
this.name = 'MyError';
}
}

Root cause:

Without setting name, error logs show generic 'Error' making it harder to identify error types.

#3 Using plain objects instead of Error instances for errors

Wrong approach:

next({ message: 'Something went wrong', statusCode: 400 });

Correct approach:

next(new ValidationError('Something went wrong'));

Root cause:

Plain objects lack stack traces and standard error properties, reducing debugging effectiveness.

Key Takeaways

Custom error classes let you create meaningful, named errors that carry extra info like HTTP status codes.

Extending the built-in Error preserves important features like stack traces and message handling.

Express error middleware can detect and respond differently based on custom error properties.

Proper error naming and stack trace capturing are crucial for effective debugging.

Using error hierarchies and consistent patterns makes your app’s error handling scalable and maintainable.

Practice

1. What is the main purpose of creating a custom error class in an Express application?

easy

A. To define specific error types with custom messages and status codes

B. To replace the Express framework's built-in error handling completely

C. To avoid using try-catch blocks in asynchronous code

D. To automatically fix errors in the application code

Solution

1. Step 1: Understand the role of custom error classes

   Custom error classes extend the built-in Error class to represent specific error types with meaningful messages and HTTP status codes.

2. Step 2: Compare with other options

   Custom errors do not replace Express error handling but improve it; they do not fix code automatically or remove the need for try-catch.

3. Final Answer:

   To define specific error types with custom messages and status codes -> Option A

4. Quick Check:

   Custom error classes = specific error types [OK]

Hint: Custom errors add meaning and status codes to errors [OK]

Common Mistakes:

• Thinking custom errors fix bugs automatically
• Believing they replace Express error middleware
• Assuming they remove try-catch necessity

2. Which of the following is the correct way to define a custom error class named NotFoundError that sets a 404 status code?

easy

A. function NotFoundError() { this.message = 'Not Found'; this.status = 404; }

B. class NotFoundError extends Error { constructor() { this.message = 'Not Found'; this.status = 404; } }

C. class NotFoundError { constructor() { this.message = 'Not Found'; this.status = 404; } }

D. class NotFoundError extends Error { constructor() { super('Not Found'); this.status = 404; } }

Solution

1. Step 1: Check class inheritance and constructor

   The custom error class must extend Error and call super() with the message to set the error message properly.

2. Step 2: Verify setting status property

   Setting this.status = 404 inside the constructor is correct for HTTP status code.

3. Final Answer:

   class NotFoundError extends Error { constructor() { super('Not Found'); this.status = 404; } } -> Option D

4. Quick Check:

   Extend Error + super() + status property = correct syntax [OK]

Hint: Always call super(message) when extending Error [OK]

Common Mistakes:

• Not calling super() in constructor
• Defining error as plain class without extending Error
• Using function instead of class for custom error

3. Given the following code, what will be the output when throw new ValidationError('Invalid input'); is caught and logged?

class ValidationError extends Error {
  constructor(message) {
    super(message);
    this.status = 400;
  }
}

try {
  throw new ValidationError('Invalid input');
} catch (err) {
  console.log(err.message, err.status);
}

medium

A. Invalid input 400

B. Invalid input undefined

C. ValidationError 400

D. Error Invalid input

Solution

1. Step 1: Understand the error message and status

   The ValidationError constructor calls super(message), so err.message is 'Invalid input'. The status property is set to 400.

2. Step 2: Check console.log output

   Logging err.message and err.status prints 'Invalid input' and 400 separated by space.

3. Final Answer:

   Invalid input 400 -> Option A

4. Quick Check:

   err.message = 'Invalid input', err.status = 400 [OK]

Hint: super(message) sets err.message; status is custom property [OK]

Common Mistakes:

• Expecting class name as message
• Assuming status is undefined
• Confusing Error default message with custom message

4. Identify the error in this custom error class definition:

class AuthError extends Error {
  constructor(message) {
    this.message = message;
    this.status = 401;
  }
}

medium

A. Constructor should not accept message parameter

B. Status code 401 is invalid for authentication errors

C. Missing call to super(message) in constructor

D. Class should not extend Error for custom errors

Solution

1. Step 1: Check constructor of subclass of Error

   When extending Error, the constructor must call super(message) to properly initialize the error message.

2. Step 2: Identify missing super call

   The code sets this.message directly but does not call super(), which causes errors in Error inheritance.

3. Final Answer:

   Missing call to super(message) in constructor -> Option C

4. Quick Check:

   Always call super(message) in Error subclass constructor [OK]

Hint: Always call super() first in Error subclass constructor [OK]

Common Mistakes:

• Setting this.message without super()
• Forgetting to extend Error
• Using wrong status codes for errors

5. You want to create a custom error class DatabaseError that accepts a message and an optional error code, defaulting to 500. Which implementation correctly supports this and sets both status and code properties?

hard

A. class DatabaseError extends Error {
constructor(message, code = 500) {
super(message);
this.status = code;
this.code = 500;
}
}

B. class DatabaseError extends Error {
constructor(message, code) {
super(message);
this.status = code || 500;
this.code = code || 500;
}
}

C. class DatabaseError extends Error {
constructor(message, code = 500) {
super(message);
this.status = 500;
this.code = code;
}
}

D. class DatabaseError extends Error {
constructor(message, code) {
this.message = message;
this.status = 500;
this.code = code || 500;
}
}

Solution

1. Step 1: Check constructor parameters and defaults

   class DatabaseError extends Error { constructor(message, code) { super(message); this.status = code || 500; this.code = code || 500; } } uses code parameter without default but uses code || 500 to set status and code, supporting optional code.

2. Step 2: Verify super call and property assignments

   super(message) is called correctly; this.status and this.code are set to code or 500 if code is falsy.

3. Step 3: Compare with other options

   class DatabaseError extends Error { constructor(message, code = 500) { super(message); this.status = 500; this.code = code; } } sets status always to 500 ignoring code parameter; class DatabaseError extends Error { constructor(message, code = 500) { super(message); this.status = code; this.code = 500; } } swaps status and code values; class DatabaseError extends Error { constructor(message, code) { this.message = message; this.status = 500; this.code = code || 500; } } misses super() call.

4. Final Answer:

   class DatabaseError extends Error { constructor(message, code) { super(message); this.status = code || 500; this.code = code || 500; } } -> Option B

5. Quick Check:

   Optional code with fallback and super() call = correct [OK]

Hint: Use code || 500 to set optional code with default [OK]

Common Mistakes:

• Ignoring super() call
• Swapping status and code values
• Not supporting optional parameter correctly