@Martin That is a good point about if I have source error listener then I shouldn't need to forward the error.
So maybe the logic could be the following for errors in a piped stream: 1. if any error listener on source, emit there only 2. else if any error listener on dest, forward the error to the dest (where that error handler can use it) 3. else throw err Currently stream.pipe does 1 and 3, so we would be adding item 2. On Wednesday, 28 November 2012 23:54:29 UTC-6, Martin Cooper wrote: > > > That depends on what you're going to do with it. As a simple example, if I > create a read stream on a tarball, pipe it through Gunzip, and pipe that > through Untar, I may well be interested in reporting to the user which one > of those things messed up if something went wrong. What I *don't* want to > have to do is muddle through inconsistently constructed Error objects to > try to figure that out for myself, if there's only one place to put my > error handler. > > In other words, I *like* the fact that the error handlers are interspersed > within my pipe setup, because it gives me flexibility in both determining, > and reporting, what went wrong. If I don't want to make use of that > flexibility, then I can reuse the same handler, as in your example. But I > have that choice. > > -- > Martin Cooper > > -- 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 nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
