fix: fall back to default format index on malformed style index (#355)

[Mikkey-f]

Fixes #355

What changes were proposed in this pull request?

CellTagHandler parses a cell's s attribute (style index) with a bare Integer.parseInt. A non-numeric value — as produced by some third-party tools — threw NumberFormatException and aborted the whole file read at the first corrupt cell (in the report: reading stopped at row 3218 of 3000+ rows).

The parse now falls back to the default format index (0) on NumberFormatException: a corrupt style index only loses that cell's style info, while the cell value and all subsequent rows are still read. This follows the reporter's suggestion and matches POI's lenient behavior (POI reads the same file completely, with the corrupt cell read as empty).

How was this patch tested?

• CellTagHandlerTest (2 new unit tests): non-numeric s falls back to dataFormatData(0) without throwing; numeric s keeps the exact lookup.
• CorruptStyleIndexReadTest (new end-to-end test): a minimal hand-built xlsx whose middle row carries s="abc" is read completely — all 3 rows returned.
• Red/green check: on the pre-fix code the e2e test fails with the exact exception from the report (NumberFormatException: For input string: "abc"); with the fix it passes.
• Full fesod-sheet suite: 915/915 green. spotless:check and javadoc pass.

Notes

• Zero impact on valid files: the numeric parse path is untouched.
• No API change, no new dependencies.

[skytin1004]

Reviewed and verified locally.

The focused tests pass locally (4 tests). I also temporarily reverted the handler change and confirmed that the end-to-end test reproduces the original NumberFormatException in CellTagHandler.

The fix is narrowly scoped, and the regression coverage verifies both the internal handler and the public read path. I also confirmed that valid numeric style indexes are still handled through the existing lookup path, so the change does not affect the normal style lookup behavior.

LGTM.

[bengbengbalabalabeng]

POI doesn't actually provide fault tolerance for this scenario during streaming reads:

Looking at the source code of XSSFSheetXMLHandler, reading the test XLSX file with POI’s native streaming API only succeeds because the test file lacks a styles.xml. Consequently, stylesTable is null, which naturally bypasses the style resolution logic. In real-world scenarios, however, as long as styles.xml is present, POI will still throw a NumberFormatException and abort the read when encountering s="abc".

https://github.com/apache/poi/blob/dca7cda1dc8a64197f7e7e8e7892ba9a0d79c860/poi-ooxml/src/main/java/org/apache/poi/xssf/eventusermodel/XSSFSheetXMLHandler.java#L265-L300

Therefore, mentioning "matching POI's lenient behavior" in the comment might not be entirely accurate. In addition, while I agree that we should be lenient with non-standard files missing styles.xml (ensuring unstyled sheets can still be processed), handling malformed data like s="abc" in a structurally complete file is a different story. Whether the framework should catch this exception—and whether it should fall back to DEFAULT_FORMAT_INDEX = 0 or simply skip it (leave it as null)—is probably worth further discussion.