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
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.
--
Job Boa
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
wrote:
> Yeah
What was problematic about it? Also I though event emitters had to be
explicitly added to domains.
On Wed, Nov 28, 2012 at 4:47 PM, 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 erro
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
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
firs
On Wed, Nov 28, 2012 at 2:05 PM, Jeff Barczewski
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
@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
The biggest problem with forwarding errors happens when you have
duplex streams that forward to one another, and as Martin points out,
streams that emit errors in different circumstances.
For example, let's say that you added something like this in the
pipe() function:
src.on('error', functio
@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
@Isaac You bring up a good point about the duplex streams, I can see how
that could get hairy real quick.
Your domains example is nice, so maybe that is the best way to handle error
in a single place.
For completeness and finishing the discussion around this, I can give one
last idea. Since p
Since pipe is used in a lot of very hot areas, and is a royal pain to
make changes to, I'd suggest just leaving it as-is for now. That pipe
option object is kind of a wart in my opinion, I'd rather not make it
bigger.
On Thu, Nov 29, 2012 at 9:50 AM, Jeff Barczewski
wrote:
> @Isaac You bring up
Understood. Thanks for all the discussion.
Using domains appears to be a good solution in addition to using individual
listeners.
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you
This is all really good info and I'm not gonna argue. I still think it'd be
nice if there was a nicer shorthand to tell one emitter to forward certain
events to another emitter. So at least it's less of a pain to do it
manually. I kinda don't think there is a good shorthand though. Even adding
it t
Marco,
Easily monkeypatched/userlanded:
Stream.prototype.pipeErr = function(dest, opt) {
var fw = dest.emit.bind(dest, 'error')
this.on('error', fw)
var self = this
dest.on('unpipe', function (src) {
if (src === self)
dest.removeListener('error', fw)
})
return this.pipe(dest
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 you
16 matches
Mail list logo
