Repository navigation
fs.promises.stat: Missing option throwIfNoEntry #61116
Description
Activity
- addedfeature requestIssues requesting new Node.js features.Issues requesting new Node.js features.
on Dec 18, 2025 I have implemented a fix for this to bring
fs.promises.statinto parity with the sync version. I'll be opening a draft PR shortly to run the CI and verify the implementation.Reacted by Rasmus SchultzHey, 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' }
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.
@mindplay-dk hey, my bad. I misread the whole thing
- added a commit that references this issue
on Dec 26, 2025 - addedfsIssues and PRs related to file-system APIs and the fs module.Issues and PRs related to file-system APIs and the fs module.
on Dec 30, 2025 is the feature added or i will make will contribution it
- added a commit that references this issue
on Feb 11, 2026 - added a commit that references this issue
on Feb 19, 2026 - added 5 commits that reference this issue
on Apr 4, 2026
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsAwaiting Triage
What is the problem this feature will solve?
For some reason
fs.promises.statis missing the optionthrowIfNoEntrythat was added tofs.statin 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.stattofs.promises.statand it would seem natural to expect the API to be the same, just async.