Custom error classes in Express - Mini Project: Build & Apply

Custom Error Classes in Express

📖 Scenario: You are building a simple Express server that handles user requests. You want to create custom error classes to manage different error types clearly and send proper responses.

🎯 Goal: Create custom error classes for NotFoundError and ValidationError, then use them in an Express route to handle errors properly.

📋 What You'll Learn

Create a base error class called AppError that extends Error

Create a NotFoundError class that extends AppError with a default message

Create a ValidationError class that extends AppError with a default message

Use these custom errors in an Express route and handle them in error middleware

💡 Why This Matters

🌍 Real World

Custom error classes help organize error handling in web servers, making it easier to send clear messages to users and debug issues.

💼 Career

Understanding custom errors and middleware is essential for backend developers working with Express or similar frameworks to build robust APIs.

1

Create the base error class

Create a class called AppError that extends the built-in Error class. It should accept message and statusCode parameters in the constructor and set them as properties.

Express

# Your code here
// Create class AppError extending Error with constructor(message, statusCode)

Hint

Remember to call super(message) inside the constructor to set the error message.

2

Create NotFoundError and ValidationError classes

Create two classes: NotFoundError and ValidationError. Both should extend AppError. The NotFoundError constructor should call super with message 'Resource not found' and status code 404. The ValidationError constructor should call super with message 'Invalid input' and status code 400.

Express

class AppError extends Error {
    constructor(message, statusCode) {
        super(message);
        this.statusCode = statusCode;
        this.name = this.constructor.name;
        Error.captureStackTrace(this, this.constructor);
    }
}

// Your code here
// Create NotFoundError and ValidationError classes extending AppError

Hint

Use super in each constructor to pass the message and status code to AppError.

3

Use custom errors in an Express route

Create an Express app. Add a GET route at /items/:id. Inside the route, if req.params.id is not '1', throw a NotFoundError. Otherwise, send JSON { id: '1', name: 'Item One' }.

Express

class AppError extends Error {
    constructor(message, statusCode) {
        super(message);
        this.statusCode = statusCode;
        this.name = this.constructor.name;
        Error.captureStackTrace(this, this.constructor);
    }
}

class NotFoundError extends AppError {
    constructor() {
        super('Resource not found', 404);
    }
}

class ValidationError extends AppError {
    constructor() {
        super('Invalid input', 400);
    }
}

const express = require('express');
const app = express();

// Your code here
// Add GET /items/:id route that throws NotFoundError if id !== '1'

Hint

Use next() to pass the error to Express error handlers.

4

Add error handling middleware

Add an Express error-handling middleware function that takes err, req, res, next. If err is an instance of AppError, respond with err.statusCode and JSON { error: err.message }. Otherwise, respond with status 500 and JSON { error: 'Internal Server Error' }. Export the app.

Express

class AppError extends Error {
    constructor(message, statusCode) {
        super(message);
        this.statusCode = statusCode;
        this.name = this.constructor.name;
        Error.captureStackTrace(this, this.constructor);
    }
}

class NotFoundError extends AppError {
    constructor() {
        super('Resource not found', 404);
    }
}

class ValidationError extends AppError {
    constructor() {
        super('Invalid input', 400);
    }
}

const express = require('express');
const app = express();

app.get('/items/:id', (req, res, next) => {
    if (req.params.id !== '1') {
        return next(new NotFoundError());
    }
    res.json({ id: '1', name: 'Item One' });
});

// Your code here
// Add error handling middleware and export app

Hint

Error middleware in Express has four parameters. Use instanceof to check error type.

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