Github user jodersky commented on the pull request: https://github.com/apache/spark/pull/9128#issuecomment-148438185 In general I agree with you, however since in this case some warnings (such as deprecations) are not treated as fatal, the user gets a huge amount of messages and there is no way to distinguish between fatal warnings and errors. This then can lead to pretty confusing debugging in case of errors. E.g. I spent an hour trying to reproduce an error that I thought might be compiler-related, only to find out it was a perfectly valid warning. As scala 2.10 does not provide any warning-discrimination out-of-the-box, I can think of a few possibilities to ease debugging: First, treat all warnings as fatal: show warnings as such then at the end display a message such as "[error] warnings are treated as fatal". This option has the inconvenience of also erroring on deprecation warnings and is thus not acceptable. Second, don't show deprecation warnings and continue as in the first option. This hides important information to the user and in my opinion is not the way to go either. Third, display all warnings and treat certain ones as errors (as is done currently) but also inform the user if it was due to a warning. This option is what I am suggesting in my PR, the user will get an error message with an additional warn tag: "[error] [warn] blablabla". If you think a different tag would be more suitable, such as [fatal warn], we can of course change the message. I hope this illustrates my idea behind the PR. Let me know what you think On Oct 15, 2015 4:32 AM, "Sean Owen" <notificati...@github.com> wrote: > I think it's OK, but what does it help? if warnings are to be treated as > errors, they are errors like others. Does it become confusing to log an > error that says "warn"? > > â > Reply to this email directly or view it on GitHub > <https://github.com/apache/spark/pull/9128#issuecomment-148360061>. >
--- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- --------------------------------------------------------------------- To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org For additional commands, e-mail: reviews-h...@spark.apache.org