fs.watch error message includes filename

[charlierudolph]

Brought over from nodejs/node-v0.x-archive#25542

[cjihrig]

Can you use let instead of var, and a template string instead of concatenation.

[cjihrig]

You changed two code paths, but only added a test for one. Can you test for the other too?

[charlierudolph]

Thanks for the review. Code comments addressed. I don't actually know how to test the other code path. which is an error occurring while watching a file. Any suggestions?

[thefourtheye]

This is not necessary.

[charlierudolph]

unfortunately it is. If the function doesn't return true, it throws the error.

[thefourtheye]

@charlierudolph Oops, sorry. My bad.

[sindresorhus]

Even if it's non-standard, might be worth going with camelCased fileName for consistency with other envs: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/fileName

[cjihrig]

One important difference is that Error.prototype.fileName indicates the file that raised the exception, while the proposed addition in this PR indicates a parameter to a file system operation.

[charlierudolph]

@cjihrig bump. Anything else this PR needs?

[thefourtheye]

This can actually be const

[cjihrig]

It LGTM, but I'd really like a test for the emit path. Would anyone object to a slightly artificial test like:

var watcher = fs.watch(__filename);
watcher._handle.onchange(-1, 'ENOENT', 'foo.js');

[charlierudolph]

okay @cjihrig the emit path now has a test.

[cjihrig]

Instead of creating watcherErrorCaught, you can just wrap this function in common.mustCall(). That way you can ensure it was called, and fail the test if it's not.

[cjihrig]

One comment, but this LGTM

[cjihrig]

Oh, and can you squash this down to a single commit?

[charlierudolph]

Switched to using common.mustCall and squashed to a single commit.

[cjihrig]

CI - https://ci.nodejs.org/job/node-test-pull-request/404/

[charlierudolph]

That build is very complex to traverse. Okay from the link provided I got to
https://ci.nodejs.org/job/node-test-binary-arm/88/RUN_SUBSET=5,nodes=pi1-raspbian-wheezy/tapTestReport/
which says test-stringbytes-external.js is what failed. I don't know how I could have made that fail, especially since no error message is provided.

The build page shows another commit is being tested in addition to mine.
https://ci.nodejs.org/job/node-test-binary-arm/88/

[thefourtheye]

Don't worry about that test. It fails often.

[cjihrig]

Thanks! Landed in 87e820e