According to the Internationalization Best Practices for Spec Developers published by W3C Internationalization Working Group, we should be providing language-independent identifiers for errors.
It seems like the code property on each of our error instances would be the most appropriate place for this, but we are currently using constant-case identifiers (e.g., ERR_MISSING_OPTION like Node.js core) for this. Depending on how these errors are being checked at run-time, and if we want to be able to maintain interop with Node.js in the future, it may be worthwhile to use a different property for the language-independent identifier, which will most likely be composed strictly of digits.
According to the Internationalization Best Practices for Spec Developers published by W3C Internationalization Working Group, we should be providing language-independent identifiers for errors.
It seems like the
codeproperty on each of our error instances would be the most appropriate place for this, but we are currently using constant-case identifiers (e.g.,ERR_MISSING_OPTIONlike Node.js core) for this. Depending on how these errors are being checked at run-time, and if we want to be able to maintain interop with Node.js in the future, it may be worthwhile to use a different property for the language-independent identifier, which will most likely be composed strictly of digits.