Any exception should break the build #72
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…t about exceptions in its formatters. Default behavior matches the existing behavior.
…and equals/hashCode with the same constraints as SerializableFileFilter. Refactored the `toBytes()` method into the interface `NoLambda`, and moved `SerializableFileFilter.EqualityBasedOnSerialization` to `NoLambda.EqualityBasedOnSerialization`. Technically a breaking change, but will affect exactly zero real-world client code.
… issues we had in the non-GIT_ATTRIBUTES policies. Since GitAttributesLineEndings.Policy uses LazyForwardingEquality, it required LazyForwardingEquality to implement NoLambda.
…hCode(), which required some serialization tricks because Charset and Path are not serializable.
… Refactored to only have one.
…ization. Turns out that it wasn't for FreshMarkStep, which has now been fixed.
…'re using it for any serializable object.
…ForPath`, but by default any exceptions will kill the build.
jbduncan
reviewed
Jan 18, 2017
There was a problem hiding this comment.
Might it be worth bumping the version number for spotless-lib anyway, even if we only bump it from 1 to 1.1 instead of 2?
Edit: Ah sorry, I'm talking about the breaking change to spotless-lib's behaviour which you introduced in e36ddab .
|
We already shipped 1.0, and we've added some features (ktlint and scalafmt), so the next release will definitely be 1.1. |
…le file, Path rootDir).
nedtwigg
force-pushed
the
feature/strictExceptions
branch
from
67ea815 to
e279153
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Right now, if any exception is thrown by a FormatterStep, it will silently print a warning and that's it. This is a problem for two reasons:
Before Spotless 3.x, the eclipse formatter would intermittently fail to due to classpath conflicts. It made sense to let these slip by so that Spotless would still be usable, but now with 3.x classloader isolation spotless is much more reliable - there's no longer any reason to let these slip by.
With up-to-date checking, it's hard to get a second chance to see an error. This is especially troublesome for rules like FreshMark.
This PR makes any exceptions fail the build, along with a mechanism to allow a specific failure to sneak by. In order to implement this functionality, it also found and fixed some bugs to make
Formatterfully support equals/hashCode/Serializable, and improved the tests.