Should Node.js standard library throw custom Error subclasses?

[Ginden]

As we know, ECMAScript define only few Error subclasses. W3C specifications adds to this list DOMException and URIError. Right now, Node.js implements seven Errors:

• Error
• EvalError
• RangeError
• ReferenceError
• SyntaxError
• TypeError
• URIError

On other side we have Java standard library that defines 74 classes extending java.lang.Exception and numerous other extending these subclasses. Most of them doesn't make sense in Node.js context, as our standard library is much smaller, but I'm convinced that 7 errors defined in ECMAScript are too general to provide meaningful information on types of error that can happen.

Therefore, I propose:

• make all exceptions coming from syscalls inherit from new class SystemError (class SystemError extends Error)
  • create classes like FileSystemError and NetworkError to inherit from SystemError
• add class DeprecationError inheriting from Errror for deprecated features
• discourage creating direct instances of Error in standard library

Disadvantages:

• code directly checking err.constructor === TypeError can break

Advantages:

• better typing for TypeScript
  • many IDEs can use TypeScript definition files and use them as ad-hoc documentation, even if you write in JavaScript
• Bluebird .catch(klass, handler) easier to use

Loose ideas:

• export classes like DatabaseError to be subclassed by database modules

I'm working on pull request to replace new Error with new TypeError or new RangeError wherever it makes sense.

[mscdex]

A couple of immediate thoughts:

• Node.js does not implement those *Error objects, V8 does
• -1 to exporting random non-core-related Error objects like DatabaseError, IMHO that is out of scope for node

[Qard]

DatabaseError probably does not makes sense. Most database errors would be NetworkError. There may be query-related errors, but those should probably be more specific to the particular database module, so I'm also -1 on that.

The other stuff sounds good to me though. Being able to type-check errors would be fantastic.

[jasnell]

Related to this is my PR #6573, which begins attaching a stable error code to every error. I need to get through and get that PR rebased and updated but it should give an idea on the direction.

[Qard]

@jasnell I like the error code idea too. I'd actually like to see both though. Error types let us group errors by category to handle them similarly. For example, there's multiple ways in which network access can error, so you may want the detail to see if retrying is a valid approach. However, in a higher level API, you may receive network errors alongside other non-network errors, so branching logic on that error type would be quite helpful. 😸

[cjihrig]

-1 to defining new error types.

[benjamingr]

I just want to point out you can use stuff like .catch in bluebird without error subclasses - by using something like https://github.com/petkaantonov/core-error-predicates .

I'm also -1 on this at this point since it seems like a lot of effort to replace a system that already works (the error codes).

[dead-claudia]

I would prefer a non-native Error subtype for Node's own errors, if anything for easier differentiation at a glance and a better ability to use them in testing (no need to reimplement Node's magic for a mock FS error).

I am 👎 for a complex error hierarchy (that's just not very idiomatic, and it's unnecessarily complex), but something like just FSError, NetworkError, CryptoError, etc. (just the high level) would suffice.

[Trott]

This issue has been inactive for sufficiently long that it seems like perhaps it should be closed. Feel free to re-open (or leave a comment requesting that it be re-opened) if you disagree. I'm just tidying up and not acting on a super-strong opinion or anything like that.

[Almenon]

@Trott Can this be re-opened please? At the very least node should have a SystemError class. With typescript becoming more and more popular the lack of types is becoming more troublesome.

[Trott]

@Trott Can this be re-opened please? At the very least node should have a SystemError class. With typescript becoming more and more popular the lack of types is becoming more troublesome.

I'm going to re-open, but I suspect this will get closed pretty quickly. I could certainly be wrong about that, though. I think there will be a lot of resistance among Node.js core devs to add this stuff and support it. But let's see....

@mscdex @benjamingr @cjihrig You're all still -1 on adding something like SystemError?