Custom error classes in Node.js - Performance & Optimization

Performance: Custom error classes

LOW IMPACT

This affects the error handling flow and stack trace generation during runtime, impacting debugging speed and error reporting performance.

Creating meaningful error types for better debugging

Node.js

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

function fetchData() {
  throw new FetchError('Failed to fetch data');
}

Custom error class adds a clear error type without extra runtime overhead, improving debugging clarity.

📈 Performance GainNo added runtime cost; improves developer efficiency.

Creating meaningful error types for better debugging

Node.js

function fetchData() {
  throw new Error('Failed to fetch data');
}

Using generic Error makes it harder to identify error source and type during debugging.

📉 Performance CostNo significant runtime cost but increases developer debugging time.

Performance Comparison

Pattern	Runtime Overhead	Stack Trace Clarity	Debugging Speed	Verdict
Generic Error	Minimal	Low (generic message)	Slower due to unclear error type	[!] OK
Custom Error Class	Minimal	High (specific error name)	Faster due to clear error type	[OK] Good

Rendering Pipeline

Custom error classes do not affect browser rendering but influence Node.js runtime error handling and stack trace generation.

→Error Creation

→Stack Trace Generation

⚠️ BottleneckStack Trace Generation can be slightly slower if error properties are complex.

Optimization Tips

1Custom error classes add minimal runtime overhead but improve error clarity.

2Avoid heavy computations in error constructors to keep stack trace generation fast.

3Use specific error names to speed up debugging and error handling.

Performance Quiz - 3 Questions

What is the main performance impact of using custom error classes in Node.js?

A Improves debugging clarity with minimal runtime cost

B Significantly slows down application startup

C Increases memory usage by hundreds of megabytes

D Blocks event loop during error creation

DevTools: Node.js Inspector (Debugger)

How to check: Run your Node.js app with --inspect flag, set breakpoints on error throw, and inspect error objects in the debugger.

What to look for: Check error.name and error.stack properties to confirm custom error class usage and clear stack traces.

Practice

1. What is the main reason to create a custom error class in Node.js?

easy

A. To define specific error types for clearer error handling

B. To make the program run faster

C. To avoid using try-catch blocks

D. To replace the built-in Error class completely

Solution

1. Step 1: Understand the purpose of custom errors

   Custom error classes help identify and handle specific error cases clearly in your code.

2. Step 2: Compare with other options

   Custom errors do not speed up code, avoid try-catch, or replace Error class but extend it.

3. Final Answer:

   To define specific error types for clearer error handling -> Option A

4. Quick Check:

   Custom error purpose = Specific error types [OK]

Hint: Custom errors clarify error types, not speed or structure [OK]

Common Mistakes:

• Thinking custom errors improve performance
• Believing custom errors remove need for try-catch
• Assuming custom errors replace built-in Error

2. Which of the following is the correct way to define a custom error class named MyError in Node.js?

easy

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

B. function MyError() { this.message = 'Error'; this.name = 'MyError'; }

C. class MyError { constructor(message) { this.message = message; } }

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

Solution

1. Step 1: Check class inheritance

   Custom errors must extend the built-in Error class to behave like errors.

2. Step 2: Verify constructor and name setting

   The constructor calls super(message) and sets this.name to the class name for clarity.

3. Final Answer:

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

4. Quick Check:

   Extend Error and set name = MyError [OK]

Hint: Extend Error and set this.name in constructor [OK]

Common Mistakes:

• Not extending Error class
• Forgetting to call super(message)
• Not setting the error name property

3. What will be the output of this code snippet?

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

try {
  throw new NotFoundError('Item not found');
} catch (e) {
  console.log(e.name + ': ' + e.message);
}

medium

A. Error: Item not found

B. NotFoundError: Item not found

C. TypeError: Item not found

D. undefined: Item not found

Solution

1. Step 1: Understand custom error name

   The custom error sets this.name = 'NotFoundError', so e.name is 'NotFoundError'.

2. Step 2: Check the output format

   The console.log prints e.name + ': ' + e.message, which becomes 'NotFoundError: Item not found'.

3. Final Answer:

   NotFoundError: Item not found -> Option B

4. Quick Check:

   Custom error name shows in output [OK]

Hint: Custom error name property appears in error output [OK]

Common Mistakes:

• Assuming default 'Error' name instead of custom
• Confusing error type with TypeError
• Missing the custom name property effect

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

class ValidationError extends Error {
  constructor(msg) {
    this.message = msg;
    this.name = 'ValidationError';
  }
}

medium

A. Missing call to super() in constructor

B. Incorrect class name

C. Should extend Object instead of Error

D. No error, code is correct

Solution

1. Step 1: Check constructor for super call

   When extending Error, constructor must call super() before using this.

2. Step 2: Identify missing super call

   The code sets this.message and this.name without calling super(msg), causing a runtime error.

3. Final Answer:

   Missing call to super() in constructor -> Option A

4. Quick Check:

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

Hint: Always call super() before using this in constructor [OK]

Common Mistakes:

• Forgetting super() call causes ReferenceError
• Setting this.message before super()
• Extending wrong base class

5. You want to create a custom error class AuthError that includes a statusCode property for HTTP status codes. Which implementation correctly adds this property and preserves the error behavior?

hard

A. class AuthError extends Error {
constructor(statusCode) {
super();
this.name = 'AuthError';
this.statusCode = statusCode;
}
}

B. class AuthError extends Error {
constructor(message, statusCode) {
this.message = message;
this.statusCode = statusCode;
this.name = 'AuthError';
}
}

C. class AuthError extends Error {
constructor(message, statusCode) {
super(message);
this.name = 'AuthError';
this.statusCode = statusCode;
}
}

D. class AuthError {
constructor(message, statusCode) {
this.message = message;
this.statusCode = statusCode;
this.name = 'AuthError';
}
}

Solution

1. Step 1: Check proper Error extension and constructor

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

2. Step 2: Verify additional property and name

   Setting this.statusCode after super() adds the extra info; setting this.name clarifies error type.

3. Final Answer:

   class AuthError extends Error { constructor(message, statusCode) { super(message); this.name = 'AuthError'; this.statusCode = statusCode; } } -> Option C

4. Quick Check:

   Extend Error, call super(message), add extra properties [OK]

Hint: Call super(message) first, then add extra properties [OK]

Common Mistakes:

• Not calling super(message) in constructor
• Not extending Error class
• Missing message parameter in super call