fs.existsSync should not throw and catch an exception in the implementation

[MetaMemoryT]

fs.execSync should be implemented in a manner that does not require throwing and catching an exception. Often while debugging a useful strategy is to break on all exceptions when searching for a problem. Having this function throw an exception just means more noise to wade through.

[cjihrig]

@MetaMemoryT could you provide a code sample to clarify what you would like to happen? It's pretty common for node to throw on bad inputs. It's even more common to throw in synchronous methods.

[MetaMemoryT]

The current implementation looks like this:

fs.existsSync = function(path) {
  try {
    nullCheck(path);
    binding.stat(pathModule._makeLong(path));
    return true;
  } catch (e) {
    return false;
  }
}

It would be nice if it looked like this:

fs.existsSync = function(path) {
  binding.existsSync(pathModule._makeLong(path));
}

and then a new ffi method was created, binding.existsSync that would not internally throw and catch a javascript exception. This would improve performance also, if it was implemented properly.

@cjihrig this is not a matter of throwing an exception on bad inputs, any path is a good input, the goal of this function is to return a Boolean representing whether or not the path exists. Throwing an exception is redundant, as it is representing the same information that this particular function is returning (a Boolean false value).

[rlidwka]

Often while debugging one must break on all exceptions when searching for a problem.

Hmm... is there a way to do that with node.js cli?

[MetaMemoryT]

with https://www.npmjs.org/package/node-inspector you can.

[cjihrig]

@MetaMemoryT ah, you're referring to existsSync() - the original issue referenced execSync().

exists() and existsSync() are well documented as "black sheep." There is work going on to replace them. See #8418 and #8714.

This can probably be closed.

[MetaMemoryT]

Oops, thanks.