Repository navigation
[Bug] Integer, Long, Short and Byte fields return wrong values when a cell is out of range #1100
Description
Search before asking
- I searched in the issues and found nothing similar.
Fesod version
main
JDK version
any
Operating system
Linux
Steps To Reproduce
@Getter
@Setter
public static class Row {
@ExcelProperty(index = 0)
private Integer phone;
}
File file = new File("overflow.xlsx");
FesodSheet.write(file).sheet()
.doWrite(Collections.singletonList(Collections.singletonList(13800138000L)));
List<Row> rows = FesodSheet.read(file).head(Row.class).headRowNumber(0).sheet().doReadSync();
System.out.println(rows.get(0).getPhone());Current Behavior
The read succeeds and prints 915236112 (that is 13800138000 mod 2^32). No exception, no warning.
Other integer types wrap the same way. The wrong value is returned in XLSX, XLS and CSV, for number cells and text cells alike:
| Field type | Cell value | Read back |
|---|---|---|
Integer |
13800138000 |
915236112 |
Short |
40000 |
-25536 |
Byte |
"300" |
44 |
Long |
Long.MAX_VALUE (XLSX/XLS, stored as a double) |
-9223372036854771616 |
Expected Behavior
An out-of-range value should throw ArithmeticException.
Anything else?
intValueExact() alone isn't enough because it also rejects any fraction.
The fix is to check the value against the type's range with BigDecimal.compareTo before narrowing and throw in the worst case.
Are you willing to submit a PR?
- I'm willing to submit a PR!
Activity
BigDataDZ commentedon Oct 7, 2026
I would like to work on this. Plan: range-check the value with BigDecimal#compareTo against the target type bounds before narrowing in the Byte/Short/Integer/Long number converters, throwing ArithmeticException on overflow, and add converter tests for in-range, out-of-range and fractional values.
nkuprins commentedon Oct 7, 2026
Thank you for your interest. There is already a corresponding fix PR (#1101) for this issue. If you'd like, you're also welcome to review it or add further comments to the discussion here.