Skip to content

fs.promises.stat: Missing option throwIfNoEntry #61116

Description

@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.

Activity

  1. azadgupta1 commented on Dec 19, 2025

    @azadgupta1
    Contributor

    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.

  2. juanarbol commented on Dec 22, 2025

    @juanarbol
    Member

    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'
    }
  3. mindplay-dk commented on Dec 23, 2025

    @mindplay-dk
    Author

    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.

  4. juanarbol commented on Dec 25, 2025

    @juanarbol
    Member

    @mindplay-dk hey, my bad. I misread the whole thing

  5. added
    fsIssues and PRs related to file-system APIs and the fs module.
    on Dec 30, 2025
  6. Anshul-mangla750 commented on Jan 3, 2026

    @Anshul-mangla750

    is the feature added or i will make will contribution it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature requestIssues requesting new Node.js features.fsIssues and PRs related to file-system APIs and the fs module.

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions