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