4 ms·
If the callback throws an error, none of the awaiting coroutines will run, and adding a catch would break the callback error propagation.
by nitely 7y ago
If the callback throws an error, none of the awaiting coroutines will run, and adding a catch would break the callback error propagation.
- wayneftw 7y agoYes, but he was giving the simplest implementation for the sake of brevity. Also, nobody said that we need callback error propagation in a priority queue to act the same exact way that callback error propagation works in a straight promise chain... but if you just want to reject all waiters in case of an error, you can do that. Take a look at sindresorhus' p-queue project - https://github.com/sindresorhus/p-queue https://github.com/sindresorhus/p-queue - which is about 40 lines of code that take care of queueing exactly the way you want. And it's easy to modify if you want to reject the whole queue in case of an error, which is something that I've done myself in the past. You can see them discussing the possibility of that feature right here - https://github.com/sindresorhus/p-queue/issues/29 https://github.com/sindresorhus/p-queue/issues/29 Long story short: Your problem is with ordering, not locking.
- nitely 7y agoEven the original solution is a lot more complex than just checking some primitive value. A lock is still needed when doing concurrency on a single thread, which is the point I'm making anyway. > Long story short: Your problem is with ordering, not locking. Look up the definition of a concurrency lock.