UnhandledPromiseRejectionWarning in node
SupernaviX opened this issue · 1 comments
Hi!
I've been introducing highland into a Node project at work, and I've noticed that I get warnings from node in certain conditions.
Specifically, when I run this snippet:
const oops = Promise.reject(new Error('muahaha'));
_(oops)
.toNodeStream()
.on('error', err => console.log('got it', err));
I see the following output:
(node:21215) UnhandledPromiseRejectionWarning: Error: muhahaha
at fail (repl:1:31)
at repl:1:3
at Script.runInThisContext (vm.js:122:20)
at REPLServer.defaultEval (repl.js:332:29)
at bound (domain.js:402:14)
at REPLServer.runBound [as eval] (domain.js:415:12)
at REPLServer.onLine (repl.js:642:10)
at REPLServer.emit (events.js:203:15)
at REPLServer.EventEmitter.emit (domain.js:448:20)
at REPLServer.Interface._onLine (readline.js:308:10)
(node:21215) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 21)
got it Error: muhahaha
at fail (repl:1:31)
at repl:1:3
at Script.runInThisContext (vm.js:122:20)
at REPLServer.defaultEval (repl.js:332:29)
at bound (domain.js:402:14)
at REPLServer.runBound [as eval] (domain.js:415:12)
at REPLServer.onLine (repl.js:642:10)
at REPLServer.emit (events.js:203:15)
at REPLServer.EventEmitter.emit (domain.js:448:20)
at REPLServer.Interface._onLine (readline.js:308:10)
(node:21215) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 21)
I think that this is happening because the promiseStream function is attaching the promise handlers inside of the new stream. Since the stream constructor is lazy when passed a function, the rejection handler is registered asynchronously; the rejection will be handled (assuming the stream is eventually consumed), but node still yells at me because it isn't handled right away.
Would it make sense to call promise.then
synchronously when building the stream, to avoid this? I think if promiseStream
constructed a new empty stream and used write
when values were available, it could preserve its current behavior without triggering node warnings.
Just came here to say that I am encountering this problem, too (3.0.0-beta.10). It doesn't affect the correct functionality and I can live with the current implementation. If more people see this as a problem, I would be happy to have a look into the proposed solution (but I am far from being an expert).