Why not subclassing error ?
class AppError extends Error{
constructor(name, httpCode, description, isOperational){
super(description);
this.httpCode = httpCode;
this.name = name;
//...other properties assigned here
}
toString(){
return `${this.name} - ${this.httpCode}`
}
}
(function one(){
(function two(){
try {
throw new AppError("this is an error !", 200, 'This is the error message');
} catch (error) {
console.error(`${error}`);
console.error(error.message);
console.error(error.stack);
}
})()
})()
@florentulve the example does subclass Error object in JS old fashion style:
//centralized error object that derives from Node’s Error
function appError(name, httpCode, description, isOperational) {
Error.call(this);
Error.captureStackTrace(this);
this.name = name;
};
appError.prototype.__proto__ = Error.prototype;
It absolutely makes sense to include some modern subclassing example, would you like to PR your nice example?
Wouldn't the catch clause imply handling Exceptions locally and not in a centralized error handler?
the custom error as a subclassed version would be awesome but as @i0natan said, if we were to handle errors centralized the catch clause would have to be removed or modified!
@BrunoScheufler @florentulve are you up for replacing the example with one that uses modern class inheritance + simple client invoking and catching? not sure whether we should see client calling and catching, at least not a complex client with function one + function two
What about using the custom Error class MDN provides? The try/catch could be striped out or handled differently.
@BrunoScheufler CustomError looks cool, is it supported in Node LTS?
I have to try that out - I'm using it on a daily basis but I have to check for LTS
@BrunoScheufler isn't it duplicated? I believe I saw PR related to this
@BrunoScheufler ping
Do you by any chance have that PR? I think this issue might be older than the PR, but I haven't checked.
See custom-error-test module.
Extending Error is a decision. It should not be marked as bad-practice altogether. I can only agree that, if you don't need it, you shouldn't complicate things.
But it can be very useful if done right. For example, HttpError and DbError might both throw a message about a "connection loss". In cases like this, best way to inspect the roots of an error might be to check via instanceof. (Especially in a promise chain, where the error thrown jumps all the way down to the catch clause.)
When it comes to errors and debugging; better be specific.
@onury the provided table within the link is awsome. Must find its way into our error section (if you like to PR it would be great).
We agree that - At the very least, one must have an implementation of an Error object that has a name/code so callee of functions can identify various issues. The exact technique is subject to various preferences?
Hello there! 👋
This issue has gone silent. Eerily silent. ⏳
We currently close issues after 100 days of inactivity. It has been 90 days since the last update here.
If needed, you can keep it open by replying here.
Thanks for being a part of the Node.js Best Practices community! 💚
@i0natan I currently don't have the time but you can use any content from the repo I mentioned if you're willing to.
Hello there! 👋
This issue has gone silent. Eerily silent. ⏳
We currently close issues after 100 days of inactivity. It has been 90 days since the last update here.
If needed, you can keep it open by replying here.
Thanks for being a part of the Node.js Best Practices community! 💚
Most helpful comment
See custom-error-test module.
Extending
Erroris a decision. It should not be marked as bad-practice altogether. I can only agree that, if you don't need it, you shouldn't complicate things.But it can be very useful if done right. For example,
HttpErrorandDbErrormight both throw a message about a "connection loss". In cases like this, best way to inspect the roots of an error might be to check viainstanceof. (Especially in a promise chain, where the error thrown jumps all the way down to the catch clause.)When it comes to errors and debugging; better be specific.