Unhandled Exception in readline interface #58289
Comments
|
It'd be useful that you paste a error stack trace. You haven't answered the "Why is that the expected behavior?" question, IMO if the read stream fails to close is different from the readline failing to close, you should listed to the |
|
Hi, this is not a bug per-se; you should be listening to the stream errors, not the readline errors. The readline is not failing, it is your stream. import { once } from 'events'
import { createReadStream } from 'fs'
import { createInterface } from 'readline'
let position = 0
const myDummyFilesystem = {
read: (fd, buffer, offset, len, pos, cb) => { buffer.write("A\n"); cb(null, ((position += 2) <= 10) ? 2 : 0, buffer) },
close: (x, cb) => { cb(new Error("close failed")) },
open: (name, flags, mode, cb) => { cb(undefined, 42) }
}
async function bad() {
const file = createReadStream('app.js', { fs: myDummyFilesystem })
const rl = createInterface({ input: file })
let lineNr = 0
rl.on('line', (line) => console.log(`bad ${++lineNr} ${line}`))
await once(file, 'close') // NOW DOES CATCH Error of the fs.close() CALL
}
async function good() {
const file = createReadStream('app.js', { fs: myDummyFilesystem })
let lineNr = 0
file.on('data', (line) => console.log(`good ..`))
await once(file, 'close') // CATCHES Error of the fs.close() CALL
}
await (good().catch(e => console.error("nice first catch", e)))
position = 0
bad().catch(e => console.error("nice second catch", e))You could consider that snippet as a solution for this. But this may raise some discussion around what events we listen to from the backing stream in readline. cc // @nodejs/streams |
|
If i fail in the the fs.read() call instead of the fs.close() call, the error is caught by the readline interface with I would expect that i either need to handle all input stream errors on my own, or that the readline interface provides an wrapper that abstracts/forwards all errors of the input stream. Output with read errors: new Code with read error: import { once } from 'events'
import { createReadStream } from 'fs'
import { createInterface } from 'readline'
let readError = new Error("read failed")
let closeError = null
let position = 0
const myDummyFilesystem = {
read: (fd, buffer, offset, len, pos, cb) => { buffer.write("A\n"); cb(readError, ((position += 2) <= 10) ? 2 : 0, buffer) },
close: (x, cb) => { cb(closeError) },
open: (name, flags, mode, cb) => { cb(undefined, 42) }
}
async function fun() {
const file = createReadStream('app.js', { fs: myDummyFilesystem })
const rl = createInterface({ input: file })
let lineNr = 0
rl.on('line', (line) => console.log(`.`))
await once(rl, 'close') // DOES NOT CATCH Error of the fs.close() CALL
}
await fun().catch(e => console.error("nice first catch", process.version, e))
readError = null
closeError = new Error("close failed")
position = 0
await fun().catch(e => console.error("nice second catch", process.version, e)) |
Uh oh!
There was an error while loading. Please reload this page.
Version
24.0.1
Platform
Subsystem
readline
What steps will reproduce the bug?
The following code creates a dummy fs that throws an error on the fs.close() call.
This error can be caught with events.once() when using the fs directly.
When using the fs together with readline, the error is not caught by events.once().
How often does it reproduce? Is there a required condition?
always
What is the expected behavior? Why is that the expected behavior?
the await once(...) also catches the error on fs.close()
What do you see instead?
Unhandled Exception error
Additional information
No response
The text was updated successfully, but these errors were encountered: