On Wed, Nov 28, 2012 at 2:05 PM, Jeff Barczewski <[email protected]>wrote:
> Agreed. Especially if the error happens after the initial connection > (which is probably when most would occur), then it won't be caught by any > try/catch so it would have to rely on domains. > > If you have setup an error handler then it is just nice to deal with it > there in one spot. > 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 [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
