-
-
Notifications
You must be signed in to change notification settings - Fork 33.2k
Closed
Labels
confirmed-bugIssues with confirmed bugs.Issues with confirmed bugs.fsIssues and PRs related to the fs subsystem / file system.Issues and PRs related to the fs subsystem / file system.
Description
- Version: v12.12.0 - v14.15.1
- Platform: platform-independent
- Subsystem: lib/internal/fs/dir.js
What steps will reproduce the bug?
Calling asynchronous version of dir.close() with dir already closed, e.g. by it's async iterator.
const fs = require('fs')
const dir = fs.opendirSync('.') // Using async function in this example just for brevity.
dir.closeSync() // In my actual code, here is an async loop over dir.entries() which may terminate in the middle.
try {
dir.close((error) => {
if(!error) return
// We never get ERR_DIR_CLOSED here...
})
} catch (error) {
// ... but here instead (but we should see only ERR_INVALID_CALLBACK here).
}
How often does it reproduce? Is there a required condition?
Always, when dir.close() is called redundantly.
What is the expected behavior?
Asynchronous functions should forward errors via callback, unless the provided callback argument itself is invalid.
What do you see instead?
Error is thrown immediately (synchronously), This is especially embarrassing with promises API:
try {
dir.close().then(() => console.log('closed the dir just now')
).catch(error => console.log('something wrong', error))
} catch (error) {
if(error.code === 'ERR_DIR_CLOSED') console.log('Oh no... again!')
else console.log('a real surprise!', e)
}
Additional information
If this behaviour is intentional, it should be documented; otherwise I would gladly provide a fix.
Metadata
Metadata
Assignees
Labels
confirmed-bugIssues with confirmed bugs.Issues with confirmed bugs.fsIssues and PRs related to the fs subsystem / file system.Issues and PRs related to the fs subsystem / file system.