Fixes a bug when failing assertions on DirectoryStream types#3036
Merged
joel-costigliola merged 1 commit intoassertj:mainfrom May 8, 2023
Merged
Conversation
ascopes
force-pushed
the
bugfix/assert-on-directory-streams
branch
2 times, most recently
from
a3da260 to
f2fdf62
Compare
Member
|
Thanks for the analysis and the PR @ascopes |
Member
joel-costigliola
left a comment
joel-costigliola
left a comment
There was a problem hiding this comment.
looks good, just minor comments
The DirectoryStream class is somewhat special because the API allows it to only support .iterator() being called at most once on any implementations. Due to the nature of how the StandardRepresentation currently works for iterable types, any assertion error that is thrown as a result of assertions failing on a DirectoryStream object can result in IllegalStateExceptions being propagated to the caller if .iterator() has already been called on the class. This can break further if using soft assertions, as the state of the class could change unexpectedly resulting in different exceptions being raised depending on the execution order. I've added a mechanism to deal with allowing the definition of so-called 'blacklisted' iterable types, just in case other cases like this appear in the JRE standard library anywhere in the future. This will prevent unexpected errors occuring when dealing with the NIO FileSystem APIs.
ascopes
force-pushed
the
bugfix/assert-on-directory-streams
branch
from
f2fdf62 to
51792a2
Compare
Contributor
Author
|
@joel-costigliola updated. Thanks for the quick response. |
Member
|
Integrated thanks @ascopes ! |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
The DirectoryStream class is somewhat special because the API allows it to only support .iterator() being called at most once on any implementations. Due to the nature of how the StandardRepresentation currently works for iterable types, any assertion error that is thrown as a result of assertions failing on a DirectoryStream object can result in IllegalStateExceptions being propagated to the caller if .iterator() has already been called on the class. This can break further if using soft assertions, as the state of the class could change unexpectedly resulting in different exceptions being raised depending on the execution order.
I've added a mechanism to deal with allowing the definition of so-called 'blacklisted' iterable types, just in case other cases like this appear in the JRE standard library anywhere in the future. This will prevent unexpected errors occuring when dealing with the NIO FileSystem APIs.
This was discovered as a result of ascopes/java-compiler-testing#450, where @marschall pointed out that the
#iterator()on aDirectoryStreamshould only be called once in some implementations.