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]
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
