You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 22, 2023. It is now read-only.
As a follow-up of a chat with @tjfontaine about making up a common standard about errors coming from Node.js core, documenting them and policies about compatibility of them across node versions:
Policies about compatibility of errors across node versions (mostly error messages).
What needs to be done
All errors coming from Node core need to be documented.
Common standard needs to be applied to all errors in Node core.
Differences between errors in v0.11 and v0.10 need to be found and merged according to policies about compatibility we agree upon.
I think that what we have right now is close to perfect when it comes to having a common standard. Most errors have a code property which allows them to be recognized.
Assuming we're okay with adding our own .code codes, I don't really see a point of adding a .name.
There are multiple issues for adding more information to errors from certain modules:
As to policies about compatibility, I believe that in stable versions we should just stick to whatever's documented, since this is what we guarantee to the user to be stable. Since we aim to document all the properties we return, I think we should be just fine.
My mind isn't set on error messages yet. Should we document them? What do other runtimes do?
The text was updated successfully, but these errors were encountered:
As a follow-up of a chat with @tjfontaine about making up a common standard about errors coming from Node.js core, documenting them and policies about compatibility of them across node versions:
What needs to be decided on?
What needs to be done
I think that what we have right now is close to perfect when it comes to having a common standard. Most errors have a
code
property which allows them to be recognized.Assuming we're okay with adding our own
.code
codes, I don't really see a point of adding a.name
.There are multiple issues for adding more information to errors from certain modules:
net
- better network error messages #7005 (PR in net: give better error messages #7285)fs
- Add .flag to EACCES errors from the fs module. #7796, BUG: fs.rename gives incorrect error message on error #685tls
- tls: better error messages for certificate validation errors #7460dns
- Include host name in DNS error message if available #8089As to policies about compatibility, I believe that in stable versions we should just stick to whatever's documented, since this is what we guarantee to the user to be stable. Since we aim to document all the properties we return, I think we should be just fine.
My mind isn't set on error messages yet. Should we document them? What do other runtimes do?
The text was updated successfully, but these errors were encountered: