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 BigIntParser.parseField when a BigInteger text field starts or ends with whitespace. The parser computes the field length up to the delimiter via nextStringLength, then checks the first and last byte with Character.isWhitespace and rejects before delegating to new BigInteger(str), which would fail anyway.

Source

Thrown at flink-core/src/main/java/org/apache/flink/types/parser/BigIntParser.java:104

     * Static utility to parse a field of type BigInteger from a byte sequence that represents text
     * characters (such as when read from a file stream).
     *
     * @param bytes The bytes containing the text data that should be parsed.
     * @param startPos The offset to start the parsing.
     * @param length The length of the byte sequence (counting from the offset).
     * @param delimiter The delimiter that terminates the field.
     * @return The parsed value.
     * @throws IllegalArgumentException Thrown when the value cannot be parsed because the text
     *     represents not a correct number.
     */
    public static final BigInteger parseField(
            byte[] bytes, int startPos, int length, char delimiter) {
        final int limitedLen = nextStringLength(bytes, startPos, length, delimiter);

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

        final String str = new String(bytes, startPos, limitedLen, ConfigConstants.DEFAULT_CHARSET);
        return new BigInteger(str);
    }
}

View on GitHub (pinned to 2f3c205e92)

Solutions

  1. Trim whitespace from the field bytes before calling parseField.
  2. Normalize CRLF input and re-export sources without column padding.
  3. Validate raw rows in an integration test with representative files to catch formatting drift early.

Example fix

// before
BigInteger v = BigIntParser.parseField(bytes, start, len, ',');

// after
String field = new String(bytes, start, len, StandardCharsets.UTF_8).trim();
BigInteger v = new BigInteger(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 BigInteger field");
}

Try / catch

try {
    BigInteger v = BigIntParser.parseField(bytes, start, len, delim);
} catch (NumberFormatException e) {
    // re-parse trimmed or divert to error side output
}

Prevention

When it happens

Trigger: Calling BigIntParser.parseField(bytes, startPos, length, delimiter) where bytes[startPos] or the byte just before the delimiter is a space, tab, or \r — e.g. the field " 42" or "42 ".

Common situations: Padded numeric columns from spreadsheet/CSV exports; trailing \r from CRLF line endings on the last field of a row; hand-built test fixtures with stray spaces.

Related errors


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