Custom error classes in Express - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a custom error class in Express?

A custom error class is a user-defined class that extends the built-in Error class to create specific error types with custom properties or messages, helping to handle errors more clearly in Express apps.

beginner

How do you create a basic custom error class in Express?

You create a class that extends Error, call super(message) in the constructor, and optionally add properties like statusCode to represent HTTP error codes.

intermediate

Why add a statusCode property to a custom error class in Express?

Adding statusCode helps middleware know which HTTP status to send in the response, making error responses clear and consistent.

intermediate

What is the benefit of using custom error classes over plain Error objects in Express?

Custom error classes let you distinguish error types easily, add extra info, and handle different errors in specific ways in middleware.

beginner

Show a simple example of a custom NotFoundError class in Express.

class NotFoundError extends Error {
  constructor(message = 'Not Found') {
    super(message);
    this.name = 'NotFoundError';
    this.statusCode = 404;
  }
}

What must a custom error class extend in Express?

A Error

B Object

C Response

D Request

Custom error classes extend the built-in Error class to inherit error behavior.

Why include a statusCode property in a custom error?

A To store HTTP status for responses

B To log errors to console

C To change request headers

D To modify URL paths

statusCode helps middleware send the right HTTP status code in the response.

Which method is called inside the constructor of a custom error class?

A new Error()

B this.error()

C extend()

D super(message)

super(message) calls the parent Error constructor with the error message.

What is a key advantage of custom error classes in Express?

A They speed up server response

B They allow specific error handling

C They reduce file size

D They replace middleware

Custom errors let you handle different errors in tailored ways.

Which property usually holds the error message in a custom error?

A name

B statusCode

C message

D stack

The message property contains the error description.

Explain how to create and use a custom error class in Express.

Think about how errors flow from route to middleware.

Describe why custom error classes improve error handling in Express applications.

Consider how different errors need different responses.

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