apache/flink · error · NumberFormatException

There is leading or trailing whitespace in the numeric field

Error message

There is leading or trailing whitespace in the numeric field.

What it means

Thrown by BigDecParser.parseField when the decimal field's text has leading or trailing whitespace. After scanning to the delimiter, the parser checks the first and last byte of the field with Character.isWhitespace and rejects the value before constructing the BigDecimal, because BigDecimal's constructor preserves whitespace-free digits strictly.

Source

Thrown at flink-core/src/main/java/org/apache/flink/types/parser/BigDecParser.java:121

     * @throws IllegalArgumentException Thrown when the value cannot be parsed because the text
     *     represents not a correct number.
     */
    public static final BigDecimal parseField(
            byte[] bytes, int startPos, int length, char delimiter) {
        if (length <= 0) {
            throw new NumberFormatException("Invalid input: Empty string");
        }
        int i = 0;
        final byte delByte = (byte) delimiter;

        while (i < length && bytes[startPos + i] != delByte) {
            i++;
        }

        if (i > 0
                && (Character.isWhitespace(bytes[startPos])
                        || Character.isWhitespace(bytes[startPos + i - 1]))) {
            throw new NumberFormatException(
                    "There is leading or trailing whitespace in the numeric field.");
        }

        final char[] chars = new char[i];
        for (int j = 0; j < i; j++) {
            final byte b = bytes[startPos + j];
            if ((b < '0' || b > '9') && b != '-' && b != '+' && b != '.' && b != 'E' && b != 'e') {
                throw new NumberFormatException();
            }
            chars[j] = (char) bytes[startPos + j];
        }
        return new BigDecimal(chars);
    }
}

View on GitHub (pinned to 2f3c205e92)

Solutions

  1. Trim the field bytes before parsing, or pre-clean the input so numeric columns contain no padding.
  2. For CRLF files, normalize line endings (\r\n -> \n) before splitting records, since a trailing \r counts as whitespace.
  3. Adjust delimiter/quote configuration so whitespace is not captured inside numeric fields.

Example fix

// before
BigDecimal v = BigDecParser.parseField(bytes, start, len, '|');

// after
String field = new String(bytes, start, len, StandardCharsets.UTF_8).trim();
BigDecimal v = new BigDecimal(field);
Defensive patterns

Strategy: validation

Validate before calling

int end = start + len;
if (len > 0 && (Character.isWhitespace(bytes[start]) || Character.isWhitespace(bytes[end - 1]))) {
    throw new IllegalArgumentException("Untrimmed BigDecimal field");
}

Try / catch

try {
    BigDecimal v = BigDecParser.parseField(bytes, start, len, delim);
} catch (NumberFormatException e) {
    String raw = new String(bytes, start, len, StandardCharsets.UTF_8);
    BigDecimal v = new BigDecimal(raw.trim()); // fallback after explicit trim
}

Prevention

When it happens

Trigger: Calling BigDecParser.parseField with a field like " 1.23" or "45.6 " — i.e. delimited text where numeric columns contain padding, spaces around delimiters, or CR characters from Windows line endings (\r trailing before a \n).

Common situations: CSV files edited in spreadsheets or exported with padded columns; Windows CRLF line endings leaving a trailing \r on the last field; fixed-width sources sliced with whitespace included.

Related errors


AI-assisted analysis of apache/flink@2f3c205e92 (2026-08-14). Data as JSON: /api/errors/14c2cb07a2fbeda9. Report an issue: GitHub.