Error APIs should make it easy to supply an error code property #241
Description
From nodejs/node#12729 (comment)
Node.js errors by convention may have a code property with a value that can be tested programmatically, as a more reliable alternative to comparing error message strings. To encourage N-API add-ons to conform to that convention, we could add APIs like napi_create_error_with_code() and napi_throw_error_with_code() that take the code value as another parameter.
Activity
mhdawson commentedon May 1, 2017
I agree encouraging the use of the code is good, would it make any sense to only offer versions that take a code ? Maybe we'd need a code to indicate no code. I'm just thinking it would be better to not have a whole bunch of functions doing the same thing.
jasongin commentedon May 1, 2017
Right, I had been thinking we could add the new APIs in a non-breaking way, but since we're still able to make breaking changes I agree it would probably be better to change the existing APIs now. I'm not sure the code should be required, but at least it would be more clear that something is missing if
nullptris passed as the code parameter.jasongin commentedon May 2, 2017
Node core also sets some other
Errorobject properties:errno,path,syscall,address,port. These are all documented at https://nodejs.org/api/errors.html#errors_system_errorsDoes it make sense to add support for a
codeproperty without also supporting all those other properties?mhdawson commentedon Jun 26, 2017
The main motivation is around this nodejs/node#11273 We want to decouple error checking from the error string. While errors generated by N-API don't necessarily fall into the same category as those generated by the Node.js itself it is probably good to encourage the use of an error code in addition to the string for the same reason. If errors require other specific values then they can probably be handled by additional n-api calls as we can't allow for all error specific values. (For example port will not apply to most error messages).
mhdawson commentedon Jun 26, 2017
So my recommendation is that we add support for an error code in order to encourage good practice and leave it at that.
mhdawson commentedon Jun 26, 2017
nodejs/node#13933
digitalinfinity commentedon Aug 31, 2017
I believe this is addressed with nodejs/node#13988