Less Obtuse Error Messages

[xjamundx]

fs.readFile('./notfound', function(err, data) {
   throw err; // Uncaught Error: ENOENT, open './notfound'
});

I was hoping we could change this to something awesome like "File not found './notfound'". In fact, I have a hunch there are a lot of obscure error messages that might be made into something a bit more user friendly. If you'd like me to take a serious stab at cataloging these I can, but I have a hunch this is enough to start the discussion.

Thanks ;-)

[brendanashworth]

For reference: errno.h

I'm not sure whether they're the official messages for the error codes, but "No such file or directory" sounds a lot better than ENOENT, especially to somebody who hasn't touched a language with those error codes. 👍

[abenhamdine]

👍

[algesten]

However for people that are used to errno.h any "user friendly" variant should contain the original code to not confuse matters. "ENOENT: No such file or directory".

[sonewman]

linking this to: #92

[xjamundx]

So I'm not super expert at node under the hood, but here's what I found about how this works.

fs.readFile calls fs.open which calls process.binding('fs') which at some point references https://github.com/libuv/libuv/ which is split into unix and win code-paths, which both handle errors differently.

https://github.com/libuv/libuv/blob/v1.x/src/win/fs.c

On the windows side these are translated into some sort of unixy error thing here:
https://github.com/libuv/libuv/blob/v1.x/src/win/error.c#L67

On the Unix side we appear to just be bubbling up the raw errors.
https://github.com/libuv/libuv/blob/v1.x/src/unix/fs.c#L180

It's unclear to me if node would take seriously the chance to shield all of the low level errors from the average devs and if they did if it would happen at the libuv level or up in actual node-land.

/ramblings

[algesten]

@xjamundx I would imagine the task is to "decorate" well known error codes with some user friendly text, but I'm very much against obfuscating the actual underlying code, and I'd imagine some codes would hit the user raw, without any decoration. To me that's node-land, not libuv. Having said that, I'm actually mildly against the original suggestion: devs should know what they're doing. If they don't understand the error, RTFM.

[badeend]

+1 for specifying the error code and error message. That way both experts and newcomers know what's up.

@algesten I think there is a difference between not knowing what you're doing and not being able to memorize all the error codes. Especially on Windows; many of the error codes seem foreign, because libuv translates them to a UNIX variant.

[chrisdickinson]

Currently, the best place to go to read about the error codes iojs returns is man 2 intro on the CLI. This information should be linked in the iojs docs. I need to tidy nodejs/node-v0.x-archive#8114 up and re-send it to this repo. Mea culpa!

[frankrousseau]

+1 about having more explicit error messages. Current error logging makes debugging slower. The new io.js documentation about error codes is a big step forward. But I think it should be included with the error output.

Info: I'm ready to code if needed.

[piscisaureus]

bc2c85c

[piscisaureus]

Closing this issue because the error messages for fs have been improved, which was what the TS asked for.
Please create a new issue if you run into unclear error messages in other areas.