apache
[Bug]: Calculator transform errors out with 'ERROR: java.lang.ArithmeticException: / by zero'
Apache Hop version?
2.16
Java version?
OpenJDK 64-Bit Server VM Temurin-21.0.3+9 (build 21.0.3+9-LTS, mixed mode, sharing)
Operating system
Windows
What happened?
I am reading data from a TXT file and perform a simple A/B calculation in the Calculator step. After a random number of rows it returns the error
2025/12/03 13:52:19 - Calculator.0 - ERROR: Unexpected error
2025/12/03 13:52:19 - Calculator.0 - ERROR: java.lang.ArithmeticException: / by zero
2025/12/03 13:52:19 - Calculator.0 - at org.apache.hop.core.row.ValueDataUtil.divideLongs(ValueDataUtil.java:752)
2025/12/03 13:52:19 - Calculator.0 - at org.apache.hop.core.row.ValueDataUtil.divide(ValueDataUtil.java:738)
2025/12/03 13:52:19 - Calculator.0 - at org.apache.hop.pipeline.transforms.calculator.calculations.math.Divide.calculate(Divide.java:47)
2025/12/03 13:52:19 - Calculator.0 - at org.apache.hop.pipeline.transforms.calculator.Calculator.calcFields(Calculator.java:253)
2025/12/03 13:52:19 - Calculator.0 - at org.apache.hop.pipeline.transforms.calculator.Calculator.processRow(Calculator.java:173)
2025/12/03 13:52:19 - Calculator.0 - at org.apache.hop.pipeline.transform.RunThread.run(RunThread.java:54)
2025/12/03 13:52:19 - Calculator.0 - at java.base/java.lang.Thread.run(Thread.java:1583)
The custom row level logging for the transform shows
2025/12/03 13:52:19 - Calculator.0 - Read row # 1 : [2025/10/01 00:00:00.000], [76403], [2025/10/01 00:00:00.000], [207104], [57.5288888889]
2025/12/03 13:52:19 - Calculator.0 - Wrote row #1 : [2025/10/01 00:00:00.000], [76403], [2025/10/01 00:00:00.000], [207104], [57.5288888889]
2025/12/03 13:52:19 - Text file input.0 - Finished processing (I=426, O=0, R=0, W=425, U=1, E=0)
2025/12/03 13:52:19 - Calculator.0 - Read row # 2 : [2025/10/01 00:00:00.000], [1528], [2025/10/01 00:00:00.000], [30107], [8.3630555556]
2025/12/03 13:52:19 - Calculator.0 - Wrote row #2 : [2025/10/01 00:00:00.000], [1528], [2025/10/01 00:00:00.000], [30107], [8.3630555556]
2025/12/03 13:52:19 - Calculator.0 - Read row # 3 : [2025/10/01 00:00:00.000], [2661], [2025/10/01 00:00:00.000], [28955], [8.0430555556]
2025/12/03 13:52:19 - Calculator.0 - Wrote row #3 : [2025/10/01 00:00:00.000], [2661], [2025/10/01 00:00:00.000], [28955], [8.0430555556]
2025/12/03 13:52:19 - Calculator.0 - Read row # 4 : [2025/10/01 00:00:00.000], [2426], [2025/10/01 00:00:00.000], [26621], [7.3947222222]
2025/12/03 13:52:19 - Filter rows.0 - Finished processing (I=0, O=0, R=425, W=401, U=0, E=0)
2025/12/03 13:52:19 - Calculator.0 - Wrote row #4 : [2025/10/01 00:00:00.000], [2426], [2025/10/01 00:00:00.000], [26621], [7.3947222222]
2025/12/03 13:52:19 - Calculator.0 - Read row # 5 : [2025/10/01 00:00:00.000], [37441], [2025/10/01 00:00:00.000], [37916], [10.5322222222]
2025/12/03 13:52:19 - Calculator.0 - Wrote row #5 : [2025/10/01 00:00:00.000], [37441], [2025/10/01 00:00:00.000], [37916], [10.5322222222]
2025/12/03 13:52:19 - Dummy (do nothing) 2.0 - Finished processing (I=0, O=0, R=401, W=401, U=0, E=0)
2025/12/03 13:52:19 - Calculator.0 - Read row # 6 : [2025/10/01 00:00:00.000], [2005], [2025/10/01 00:00:00.000], [189], [0.0525]
I am filtering out all records that have NULL values but still it returns the error. Sample data and demo is attached.
Issue Priority
Priority: 3
Issue Component
Component: Transforms
Hi @maxbobse,
This is somewhat a bug but not completely a bug.
You are reading your input fields as Integers so the divide is done using integer values the line that is giving the error is 189/0 and you are not allowed to divide by 0.
The bug could be, filter rows is letting 0.xxx pass even though it should be an Integer compare.
But the simple solution would be to define your input fields as numbers and the error is gone.
Hi @hansva You are right, it gets fixed by changing the one input to Numbers as data type (linequantity_sum was Integer before and delta_time_hr remains Number) :)
Just wondering, would it make sense to add some kind of callout to the Calculator transform when it detects that you are mixing Int and Numbers in the A/B calculation?
Otherwise I could also offer to make an update to the transform's documentation and highlight that issue if you don't mind.
