-
Notifications
You must be signed in to change notification settings - Fork 147
Description
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.