Errors handling example why not subclassing Eror ? about nodebestpractices HOT 14 CLOSED

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.

from nodebestpractices.

@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;

https://github.com/i0natan/nodebestpractices/blob/master/sections/errorhandling/useonlythebuiltinerror.md

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?

from nodebestpractices.

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!

from nodebestpractices.

@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

from nodebestpractices.

What about using the custom Error class MDN provides? The try/catch could be striped out or handled differently.

from nodebestpractices.

@BrunoScheufler CustomError looks cool, is it supported in Node LTS?

from nodebestpractices.

I have to try that out - I'm using it on a daily basis but I have to check for LTS

from nodebestpractices.

@BrunoScheufler isn't it duplicated? I believe I saw PR related to this

from nodebestpractices.

@BrunoScheufler ping

from nodebestpractices.

Do you by any chance have that PR? I think this issue might be older than the PR, but I haven't checked.

from nodebestpractices.

@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?

from nodebestpractices.

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! 💚

from nodebestpractices.

@i0natan I currently don't have the time but you can use any content from the repo I mentioned if you're willing to.

from nodebestpractices.

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! 💚

from nodebestpractices.