mismatch between ENOENT in require('constants') and UV ENOENT

[defunctzombie]

I am not sure about the other error codes, but the value used in require('constants') for ENOENT is showing up as '2'. However, when I do a stat on a non existent file/folder, the errno is actually 32. This value corresponds to the UV_ENOENT enum value but not the ENOENT system value.

Some questions:

1. Is there a reason the UV ENOENT value is set to something different than the system value?
2. is require constants deprecated? How else would one be able to examine the error codes?
3. If it is not deprecated, should it be updated to use the UV constants vs the system ones?

[tshinnic]

libuv internal constants may or may not be the same as any particular platform's error codes. The overall issue is with libuv integration and getting consistent error codes returned. There is translation to-and-from libuv internal error code values that isn't quite correct yet. I think that eventually the error codes returned to user code will match the constants values, but they're not 'ready' yet?

This issue is likely one of the set of libuv error code return problems. See also related

#1883: "v0.5.9 fails to return EISDIR error on fs.read() of a directory"

#1889: "Error: write UNKNOWN exception"

BTW: Who is the "issue flag/tag fairy" now? These should be tagged "libuv-integration" and maybe there should be tags like "exceptions" or "errors" ?

[bnoordhuis]

1. Is there a reason the UV ENOENT value is set to something different than the system value?

Not all platforms have ENOENT.

2. is require constants deprecated? How else would one be able to examine the error codes?

Yes. It's going be removed some time in the future. You won't need it any more, error codes will be strings ("ENOENT") instead of numbers.

[defunctzombie]

Is this still an issue? Or did the noted libuv changes go through?

[piscisaureus]

Yes, this has been resolved a long time ago.