Failing Asserts on .NET Standard 2.x (fixes #267, fixes #301) #299
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.
This fixes #267 by converting these asserts that were intended for control flow during testing into
InvalidOperationException
s. In the test framework, we are still throwingLucene.Net.Diagnostics.AssertionException
in order to differentiate an "assert" from other cases that are throwingInvalidOperationException
.This is similar to how Lucene 8.x behaves, and only affects legacy codecs for
Lucene3x
andLucene40
.As for
BlockTreeTermsWriter
, its assert was failing due to lack of validation on thePrefix
to ensure it is valid UTF-8. Since the problem is only when building the string in the assert, a private method was added to generate the string by catching exceptions due to invalid UTF-8 and falling back to just writing out the display of bytes inBytesRef
.