4 ms·
Sometimes you just want an error to bubble up and be caught above. There's absolutely no reason to catch every rejection in the scope where the promise was crea
by jamesrom 10y ago
Sometimes you just want an error to bubble up and be caught above. There's absolutely no reason to catch every rejection in the scope where the promise was created.
- deleted 10y ago[deleted]
- danneu 10y agoYeah, looks like it just checks on nextTick, so it only warns when you don't attach a handler synchronously. Versus warning only if it's unreachable (like on garbage collection). Though it does emit another message when rejection is handled asynchronously. > var p = new Promise((_, reject) => reject('lol')) \ setTimeout(() => p.catch(() => console.log('handled')), 0) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 5): lol PromiseRejectionHandledWarning: Rejection handled asynchronously (rejection id: 5) Consolation prize? Fortunately, most of the run of the mill promises I can think of off the top of my head get rejection handlers attached synchronously, like in upstream middleware. I might be drawing a blank, though.