Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pass error from stream #46

Closed
wants to merge 15 commits into from
Closed

Conversation

popomore
Copy link

stream will not emit end when emit error

You can review the testcase, it will not emit task_err/err using the origin code.

@robrich
Copy link
Owner

robrich commented May 21, 2014

This one's a hard one. Sometimes emitting error stops the stream, sometimes it doesn't, and an end or finish or close event signals that stuff happened afterwards. I haven't been able to find a deterministic cause for this.

@popomore
Copy link
Author

Can you use streamEndFunc with error too, make sure the callback run only once.

@robrich
Copy link
Owner

robrich commented May 22, 2014

I can, and that's what you've done in your PR, but if the task is not really done yet, bad things happen -- even though the callback was only called once. Imagine that the clean task errors, you handle it, but it's not done yet. Then the build task kicks off and first sees if the target dir exists then fills it. It checks that it exists, and it does (clean hasn't finished yet), then clean actually finishes deleting the dir, then build tries to write a file into the dir. Boom -- write to a folder that doesn't exist. What actually failed? Clean lasted longer than you expected.

@popomore
Copy link
Author

I think we should exit the process if clean task catch a error, not continuing to run the build task.

Now we can't catch the error because of stream will not emit the end event, and can't handle err event in orchestrator.

The only thing I can do is handle the stream directly, but I don't think this's a good way.

gulp.task('read', function(cb) {
  fs.createReadStream('a.js')
    .on('error', cb)
    .on('end', cb);
}

@laurelnaiad
Copy link

Due to the fact that plugins generally don't behave consistently with respect to events around errors, I've been planning to handle each plugin's error event manually -- something that I am loathe to do, but in order to figure out where a fairly long stream goes bad and opt for the outcome that I want on a case by case basis, it seems like the only way. Would be great if there was some way to set a flag when you invoke a plugin that specified how you wanted stream errors to be handled, but this would involve gulp or orchestrator inserting itself into streams all over the place to help me with such a flag's instruction... so I'm pretty much resigned to it.

@yocontra
Copy link
Contributor

@stu-salsbury We have an issue open for this already

gulpjs/gulp#358
gulpjs/gulp#359

@popomore
Copy link
Author

@robrich @contra do you suggest to use gulp-plumber handling the error?

@phated
Copy link
Contributor

phated commented Jun 30, 2014

A fix for this has been published as 0.3.4. Please npm update.

@phated phated closed this Jun 30, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants