romseygeek commented on code in PR #16891:
URL: https://github.com/apache/lucene/pull/16891#discussion_r4375482352


##########
lucene/core/src/java/org/apache/lucene/codecs/lucene90/compressing/Lucene90CompressingStoredFieldsReader.java:
##########
@@ -694,20 +695,23 @@ public void document(int docID, StoredFieldVisitor 
visitor) throws IOException {
       final long infoAndBits = doc.in.readVLong();
       final int fieldNumber = (int) (infoAndBits >>> TYPE_BITS);
       final FieldInfo fieldInfo = fieldInfos.fieldInfo(fieldNumber);
+      if (fieldInfo == null) {
+        throw new CorruptIndexException(
+            "Unknown field number: " + fieldNumber + ", docID=" + docID, 
fieldsStream);
+      }
 
       final int bits = (int) (infoAndBits & TYPE_MASK);
-      assert bits <= NUMERIC_DOUBLE : "bits=" + Integer.toHexString(bits);

Review Comment:
   OK, I think this was a leftover from a different version of the test that 
tried to go through the whole `document()` API rather than hitting `readField` 
directly.  Bringing the assertion back works.
   
   Perhaps we should try and clarify what these various assertions and 
exceptions are trying to achieve?  We want to test that we are writing and 
reading data correctly, which is what the assertions are for.  But we also want 
to detect bit flips or bad disks or overwritten data in production, and 
assertions can't help there.  Maybe we should look at making the read side 
throw plain IOException and IllegalStateException and move all the fine-grained 
segment-level error checking stuff into CheckIndex?  So production cases catch 
general exceptions and can run CheckIndex if it looks like it's a data issue 
rather than something like a network problem?  And then CheckIndex gives us 
nice error messages and points to individual segments and files.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to