Repository navigation
emit after 'error' #28710
Description
I believe the events allowed to be emitted after error should be rather limited.
Based on the test suite I've found the following exceptions:
exit,disconnectandclose, should be ok.unpipe, maybe ok?
I've fixed some:
Then there are a lot of possible cases that might need fixing:
https://gist.github.com/ronag/b5728ae5db305abaff9955da5b47a5c9
I've found these by updating EventEmitter.prototype.emit with:
if (this._emittedError) {
if (!['close', 'exit', 'disconnect'].includes(type)) {
throw new Error("unexpected event: " + type);
}
} else if (type === 'error') {
this._emittedError = true;
}Is this worth to further look into?
Activity
rexagod commentedon Mar 13, 2020
ping @mcollina
mcollina commentedon Mar 14, 2020
emit()is a leaky abstraction: there is nothing stopping anybody to call it and emit an event. The individual cases should be fixed if they do not cause too many regressions.rexagod commentedon Mar 14, 2020
@ronag I was wondering if it would be okay to allow 'error' events as well? Like the one here. Throwing before all subsequent errors are thrown would prevent those error logs from being shown.
ronag commentedon Mar 14, 2020
In at least streams we don't want/allow multiple error events.
rexagod commentedon Mar 14, 2020
I see. So are we talking about different behaviour for different modules (subsequent errors not allowed in streams but allowed in crypto (or similar ones))?
ronag commentedon Mar 14, 2020
Yea, I guess so. I would rather it would be consistent everywhere but achieving that is a high goal. I think we should start focusing on making it sensible, e.g.
'close''error'etc...
ronag commentedon Mar 14, 2020
Here is an updated list based on master in case you want to have a go at it https://gist.github.com/ronag/3c4fdf8f73e2671efa8b9456d7bc4746
ronag commentedon Mar 14, 2020
ronag commentedon Mar 14, 2020
I think all of the most important issues with post
'error'events have been resolved or has PR's now. Except for:'close', 'exit', 'disconnect', 'removeListener', 'unpipe', 'error'which I think is ok.Next step (if any) would be to ensure
'error'is only emitted once and'close'is always last.ronag commentedon Mar 15, 2020
There is work left to do on events after
'close'https://gist.github.com/ronag/c733ec3df54350964f2ead7dec6590e0stream: don't emit 'finish' after 'error'
http: don't emit 'finish' after 'error'
stream: don't emit 'finish' after 'error'
http: don't emit 'finish' after 'error'
http: don't emit 'finish' after 'error'
stream: don't emit 'finish' after 'error'
stream: don't emit 'finish' after 'error'
http: don't emit 'readable' after 'close'
http: don't emit 'readable' after 'close'
http: don't emit 'finish' after 'error'
http: don't emit 'readable' after 'close'