Fixes #51. Prevents hard failure and lets tasks like watch keep running

[eddiemonge]

No description provided.

[sapegin]

Is grunt watch --debug not enough to solve this problem?

[eddiemonge]

no, thats not the point. If grunt watch is running and stylus has an issue, like not finding a file or a problem with the parsing the code, it kills watch. Other tasks report the error and keep watch running. Having to see the issue, fix it, and then restart the watch command is one step too many.

[sapegin]

Never have problems with --debug.

In my opinion tasks should fail if there are some problems and if they are not started with --debug option.

[martinheidegger]

@sapegin There are different sort of problems. Some problems are unfixable (broken grunt config settings for example or missing important executables) that will not be fixed unless you restart grunt. However, other problems are fixable without changing the grunt settings (i.e. by fixing the .styl file). In the grunt-sass task any problem it will output that problem in the browser as well as in the command line and watch continues to work - very comfortable. (I agree with @eddiemonge +1)

[hurrymaplelad]

I'm a little confused. I agree with @eddiemonge that grunt-contrib-stylus should play nice with grunt-contrib-watch, and with @sapegin that tasks should fail when they hit errors. Failing on errors usually means calling grunt.warn. I've seen two strategies for playing nice:

1. grunt-shell has an explicit failOnError option and avoids calling grunt.warn when it's set.
2. grunt-contrib-watch has a forever option that clobbers grunt.warn

But the changes in this PR don't prevent grunt.warn from being called (which leads to process.exit), and they seem to introduce a potential silent error. Maybe a test would help me understand when we expect stylus.render to throw instead of calling its callback with an error, and why we would want to squash that error.

[hurrymaplelad]

Shouldn't we grunt.fail.warn here?

[vladikoff]

gruntjs/grunt#1163