fs.promises.stat: Missing option throwIfNoEntry

[mindplay-dk]

What is the problem this feature will solve?

For some reason fs.promises.stat is missing the option throwIfNoEntry that was added to fs.stat in version 14/15.

What is the feature you are proposing to solve the problem?

Add the option for parity with the sync version of this function.

What alternatives have you considered?

The only alternative is a try/catch, which creates an annoying scoping issue you have to work around.

It's just surprising, when converting some code from fs.stat to fs.promises.stat and it would seem natural to expect the API to be the same, just async.

[azadgupta1]

I have implemented a fix for this to bring fs.promises.stat into parity with the sync version. I'll be opening a draft PR shortly to run the CI and verify the implementation.

[juanarbol]

Hey, thanks for opening this issue, may I ask, why throwing an exception in callbacks and promises?

The async version will use callbacks to show u errors, and the async/promisified... you can handle those in the catch or whatever you use for error handling. Throwing an exception makes sense in a sync context, in async, you'll eventually call your callbacks or error handlers for promises.

> fs.stat('/tmp/foo.js', console.error)
undefined
> [Error: ENOENT: no such file or directory, stat '/tmp/foo.js'] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'stat',
  path: '/tmp/foo.js'
}
> fs.promises.stat('/tmp/foo.js').catch(console.error)
Promise {
  <pending>,
  Symbol(async_id_symbol): 467,
  Symbol(trigger_async_id_symbol): 462
}
> Error: ENOENT: no such file or directory, stat '/tmp/foo.js'
    at async Object.stat (node:internal/fs/promises:1040:18) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'stat',
  path: '/tmp/foo.js'
}

[mindplay-dk]

Hey, thanks for opening this issue, may I ask, why throwing an exception in callbacks and promises?

@juanarbol sorry, I'm not sure what you're asking? I'm trying to avoid throwing.

My current workaround is fs.promises.stat(resourcePath).catch(() => null), which is simple enough and achieves the same thing.

It's more the inconsistency that bothers me - the fact that you need to do two completely different things with the sync/async versions of the same function is just not intuitive. I figured it out, of course. It just creates unnecessary friction when refactoring - I figured I'd report it since others are sure to run into this when refactoring between sync/async.