Skip to content

Removed --stack option to always print stack traces for errors - #864

Open
ChrisWren wants to merge 1 commit into
gruntjs:mainfrom
ChrisWren:stack
Open

Removed --stack option to always print stack traces for errors#864
ChrisWren wants to merge 1 commit into
gruntjs:mainfrom
ChrisWren:stack

Conversation

@ChrisWren

Copy link
Copy Markdown

I have seen so much frustration from grunt users not knowing about --stack. I don't see why you wouldn't want to see a stack trace when an error occurs.

@sindresorhus

Copy link
Copy Markdown
Member

👍

1 similar comment
@passy

passy commented Aug 3, 2013

Copy link
Copy Markdown

👍

@shama

shama commented Aug 4, 2013

Copy link
Copy Markdown
Member

+1 for Grunt v0.5 :)

@shama

shama commented Aug 6, 2013

Copy link
Copy Markdown
Member

FWIW, you can add grunt.option('stack', true); at the top of your gruntfile to have it always display now.

@sindresorhus

Copy link
Copy Markdown
Member

@shama it's easier to just alias grunt=grunt --stack, but most will know neither of these workarounds.

@passy

passy commented Aug 7, 2013

Copy link
Copy Markdown

Exactly. The real issue is that we're getting tons of bug reports without
--stack turned on which causes an avoidable feedback loop.

Pascal Hartig
Software Engineer

http://passy.me/
Twitter: https://twitter.com/passy
Google+: http://gplus.to/passy

On Wed, Aug 7, 2013 at 9:55 AM, Sindre Sorhus notifications@github.comwrote:

@shama https://github.com/shama it's easier to just alias grunt=grunt
--stack, but most will know neither of these workarounds.


Reply to this email directly or view it on GitHubhttps://github.com//pull/864#issuecomment-22235375
.

@adamstallard

Copy link
Copy Markdown

👍

@cowboy

cowboy commented Sep 18, 2013

Copy link
Copy Markdown
Member

So here's the problem. How do we know that an error is expected vs unexpected? For example, when a task fails, it's because an exception is thrown—and handled—but thrown nonetheless.

In fact, while you can return false; or done(false) inside a task to fail it, you can also throw new Error('...'); as well. How does Grunt differentiate between an expected and unexpected error?

I mean, I could maybe have it auto-dump a stack trace on ReferenceError but I don't want it to show a stack trace all the time.

Any suggestions?

@cowboy

cowboy commented Sep 18, 2013

Copy link
Copy Markdown
Member

One thought is to look @ the paths in the stack trace, and if any of them exist outside of Grunt or your project's node_modules folder, dump the stack trace automatically. Or something similar.

Looking for ideas here, thanks!

@vladikoff

Copy link
Copy Markdown
Member

@sindresorhus

Copy link
Copy Markdown
Member

I'm stumped

@ChrisWren

Copy link
Copy Markdown
Author

In fact, while you can return false; or done(false) inside a task to fail it, you can also throw new Error('...'); as well. How does Grunt differentiate between an expected and unexpected error?

How about not letting grunt plugin authors throw errors to be caught by Grunt, instead they are forced to use grunt.fail.fatal or done(false)? If an error is throw it is assumed to be unexpected.

@bevacqua

Copy link
Copy Markdown

+1 forcing plugin authors to grunt.fail

@jzaefferer

Copy link
Copy Markdown
Member

you can also throw new Error('...'); as well

That should be an unexpected error and logged. Task authors should be encouraged to make a task fail properly without throwing exceptions.

Was that the only concern?

Base automatically changed from master to main March 22, 2021 14:45
@gruntjs gruntjs deleted a comment from cvrebert Aug 2, 2026
@gruntjs gruntjs deleted a comment from ralphtheninja Aug 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants