What if your app could tell exactly what went wrong, every time?
Why Custom error classes in Node.js? - Purpose & Use Cases
Start learning this pattern below
Jump into concepts and practice - no test required
Imagine you have many different errors in your Node.js app, like 'User not found', 'Payment failed', or 'Invalid input'. You try to handle them all with just one generic error message.
Using only generic errors makes it hard to know what went wrong. You spend extra time checking error messages or codes manually, which can be confusing and slow down fixing bugs.
Custom error classes let you create specific error types for each problem. This way, your code can catch and handle each error clearly and easily, making your app more reliable and your debugging faster.
throw new Error('Something went wrong');class UserNotFoundError extends Error { constructor(message) { super(message); this.name = 'UserNotFoundError'; } } throw new UserNotFoundError('User not found');
Custom error classes enable precise error handling and clearer code, making your app easier to maintain and debug.
When a user tries to log in with wrong credentials, a custom InvalidCredentialsError can show a specific message and trigger a special response, improving user experience.
Generic errors hide the real problem and slow debugging.
Custom error classes create clear, specific error types.
This leads to cleaner code and easier error handling.
Practice
Solution
Step 1: Understand the purpose of custom errors
Custom error classes help identify and handle specific error cases clearly in your code.Step 2: Compare with other options
Custom errors do not speed up code, avoid try-catch, or replace Error class but extend it.Final Answer:
To define specific error types for clearer error handling -> Option AQuick Check:
Custom error purpose = Specific error types [OK]
- Thinking custom errors improve performance
- Believing custom errors remove need for try-catch
- Assuming custom errors replace built-in Error
MyError in Node.js?Solution
Step 1: Check class inheritance
Custom errors must extend the built-in Error class to behave like errors.Step 2: Verify constructor and name setting
The constructor calls super(message) and sets this.name to the class name for clarity.Final Answer:
class MyError extends Error { constructor(message) { super(message); this.name = 'MyError'; } } -> Option DQuick Check:
Extend Error and set name = MyError [OK]
- Not extending Error class
- Forgetting to call super(message)
- Not setting the error name property
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);
}Solution
Step 1: Understand custom error name
The custom error sets this.name = 'NotFoundError', so e.name is 'NotFoundError'.Step 2: Check the output format
The console.log prints e.name + ': ' + e.message, which becomes 'NotFoundError: Item not found'.Final Answer:
NotFoundError: Item not found -> Option BQuick Check:
Custom error name shows in output [OK]
- Assuming default 'Error' name instead of custom
- Confusing error type with TypeError
- Missing the custom name property effect
class ValidationError extends Error {
constructor(msg) {
this.message = msg;
this.name = 'ValidationError';
}
}Solution
Step 1: Check constructor for super call
When extending Error, constructor must call super() before using this.Step 2: Identify missing super call
The code sets this.message and this.name without calling super(msg), causing a runtime error.Final Answer:
Missing call to super() in constructor -> Option AQuick Check:
Always call super() first in subclass constructor [OK]
- Forgetting super() call causes ReferenceError
- Setting this.message before super()
- Extending wrong base class
AuthError that includes a statusCode property for HTTP status codes. Which implementation correctly adds this property and preserves the error behavior?Solution
Step 1: Check proper Error extension and constructor
The class must extend Error and call super(message) to set the error message correctly.Step 2: Verify additional property and name
Setting this.statusCode after super() adds the extra info; setting this.name clarifies error type.Final Answer:
class AuthError extends Error { constructor(message, statusCode) { super(message); this.name = 'AuthError'; this.statusCode = statusCode; } } -> Option CQuick Check:
Extend Error, call super(message), add extra properties [OK]
- Not calling super(message) in constructor
- Not extending Error class
- Missing message parameter in super call
