Join GitHub today
timers: reschedule interval even if it threw #20002
Node.js currently doesn't match browser behaviour when it comes to intervals that throw during their execution. In all browsers, the interval continues running but in Node.js it will never be rescheduled after a throw nor will the destroy async hook for that interval fire.
This is a semver-major change and IMO bringing us in line with the browsers is a good idea. If someone is handling
IMO this is a pretty well documented behaviour of
I'm fine with getting this in v11 instead of v10 and going from there, if that's preferable.
referenced this pull request
Apr 13, 2018
I don't see a compelling enough reason to change this behavior. Firstly, it has been like this from the start, and no one has complained so far (or at least, it's not linked in the issue). Secondly, it can introduce memory leaks or prevent processes from exiting while before they were working fine (the failing
setInterval will keep the event loop spinning).
I'm happy to discuss and change my mind on this. What is the reason to make this change apart from increasing web compatibility? Moreover, how increasing web compatibility would benefit Node.js in this API?
The common case remains the same. Both bail the same. However,
This seems like a good thing, though. I didn't try real domains, but making an error handling abstraction using
I don't see much problem with it that can't be caused already, and it does seem to have an actual use-case. This seems to fix a bug in
That being said, that doesn't "match browser behaviour". Browser behavior does not bail on the page, it bails only on the execution 'stack', back to an interaction, I/O, or timeout. Kinda like always having a no-op
@mcollina, any further thoughts on this?
CI after rebase: https://ci.nodejs.org/job/node-test-pull-request/14567/