Tickling this thread since I just wasted a few hours scratching my head
expecting code that looked a lot like what Jeff wrote below to work. It
doesn't.
Kind Node Keepers: the streams docs could use some attention and examples
on error handling in a multi-step stream pipeline.
Thanks for your good work,
George
On Thursday, November 29, 2012 8:51:18 AM UTC-8, Jeff Barczewski wrote:
>
> @Dominic Yes, IO errors would be primary need, but also some pass-through
> streams that parse data could also emit errors (if the data wasn't as
> expected) which we would want to handle at the final error handler.
>
> So a concrete example using some simple pass-through streams:
>
> rstream // input stream coming in to http server
> .pipe(digestStream) // calculates the sha1
> .pipe(zlib.createGzip()) // compress the data
> .pipe(redisWStream) // store it in db
> .on('error', handleError) // will respond back to user with
> appropriate message for error
>
> .on('end', storeDigestMetaInDB); // record the digest in meta info
> in db
>
>
>
> Since I did not add any other error handlers at the individual levels, but
> since I do have one at the end of the chain, it would seem logical, that
> any error emitted in the chain would end up in the final error handler. The
> pipe is composing these streams together, so it would seem that errors
> should propagate through as well.
>
> If I had not added a final error handler at all, then you have no choice
> but to just throw and let the domain catch it.
>
>
>
> On Wednesday, 28 November 2012 22:52:40 UTC-6, Dominic wrote:
>>
>> Thinking about this, usually each stream produces errors in a special way,
>> normal javascript errors, (like property of null, etc) throw instead of
>> emitting,
>> so there is no way to catch the error. domains fit this case.
>>
>> Usually, only streams that actually do IO emit errors, which is mostly
>> the first and/or last stream in the pipeline. maybe parsing errors in the
>> middle, though.
>>
>> Of course, there are many ways use streams, can you give some concrete
>> examples of a particular problem you are solving with streams where passing
>> the errors on is desirable?
>> or how you would like to catch the errors and why it's best?
>>
>>
>>
>>
>> On Wed, Nov 28, 2012 at 4:48 PM, Dan Milon <[email protected]> wrote:
>>
>>> Technically you could explicitly add each stream to its own domain.
>>>
>>> danmilon.
>>>
>>> On 11/29/2012 02:47 AM, Mikeal Rogers wrote:
>>> > with domains, these will all get trapped in the same domain because
>>> > they are all event emitters, if they throw.
>>> >
>>> > i tried forwarding errors through pipe chains but it ended up
>>> > being problematic and i've since backed off.
>>> >
>>> > On Nov 28, 2012, at November 28, 20121:24 PM, Marco Rogers
>>> > <[email protected] <mailto:[email protected]>> wrote:
>>> >
>>> >> Yeah I wish there was a better story for this. It's easy to
>>> >> forward errors. It could become difficult to determine in what
>>> >> context the error was thrown.
>>> >>
>>> >> :Marco
>>> >>
>>> >> On Wednesday, November 28, 2012 9:10:51 AM UTC-8, Jeff Barczewski
>>> >> wrote:
>>> >>
>>> >> I was recently testing some stream piping like
>>> >>
>>> >> rstream .pipe(foo) .pipe(bar) .on('error', function (err) { //
>>> >> handle the error });
>>> >>
>>> >> and I found out that currently stream.pipe does not forward the
>>> >> 'error' events, so if you wanted to handle the errors you would
>>> >> need to do something like
>>> >>
>>> >> rstream .on('error', handleError) .pipe(foo) .on('error',
>>> >> handleError) .pipe(bar) .on('error', handleError);
>>> >>
>>> >> or possibly rely on domains to deal with the error, but I would
>>> >> prefer to leave domains for other more catastrophic errors and
>>> >> just deal with errors at the end of the pipe chain.
>>> >>
>>> >> The current node.js code checks to see if the source has any
>>> >> error listeners and if there are none then it throws an Error. If
>>> >> there was an error listener on the source then it will be given
>>> >> the error to deal with.
>>> >>
>>> >>
>>> >> So to all the experienced streams users out there,
>>> >>
>>> >> 1. How do you believe it should work? (or is there a better way)
>>> >> 2. Is there any edge cases that we need to consider if we were
>>> >> to implement as I described above?
>>> >>
>>> >>
>>> >> Thanks in advance for your input!
>>> >>
>>> >> Jeff
>>> >>
>>> >>
>>> >> -- Job Board: http://jobs.nodejs.org/ Posting guidelines:
>>> >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>>> >>
>>> >>
>>> You received this message because you are subscribed to the Google
>>> >> Groups "nodejs" group. To post to this group, send email to
>>> >> [email protected] <mailto:[email protected]> To
>>> >> unsubscribe from this group, send email to
>>> >> [email protected]
>>> >> <mailto:[email protected]> For more options,
>>> >> visit this group at
>>> >> http://groups.google.com/group/nodejs?hl=en?hl=en
>>> >
>>> > -- Job Board: http://jobs.nodejs.org/ Posting guidelines:
>>> > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>>> >
>>> >
>>> You received this message because you are subscribed to the Google
>>> > Groups "nodejs" group. To post to this group, send email to
>>> > [email protected] To unsubscribe from this group, send email
>>> > to [email protected] For more options, visit this
>>> > group at http://groups.google.com/group/nodejs?hl=en?hl=en
>>>
>>> --
>>> Job Board: http://jobs.nodejs.org/
>>> Posting guidelines:
>>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>>> You received this message because you are subscribed to the Google
>>> Groups "nodejs" group.
>>> To post to this group, send email to [email protected]
>>> To unsubscribe from this group, send email to
>>> [email protected]
>>> For more options, visit this group at
>>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>>
>>
>>
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
