risingwavelabs/risingwave · error · ExprError

Numeric out of range

Error message

Numeric out of range

What it means

ExprError::NumericOutOfRange is a generic out-of-range error raised by numeric operations (arithmetic, casts) whose result exceeds the destination type's representable range, when no more specific variant applies.

Source

Thrown at src/expr/core/src/error.rs:58

/// The error type for expression operations.
#[derive(Error, ReportDebug)]
pub enum ExprError {
    /// A collection of multiple errors in batch evaluation.
    #[error("multiple errors:\n{1}")]
    Multiple(ArrayRef, MultiExprError),

    // Ideally "Unsupported" errors are caught by frontend. But when the match arms between
    // frontend and backend are inconsistent, we do not panic with `unreachable!`.
    #[error("Unsupported function: {0}")]
    UnsupportedFunction(String),

    #[error("Unsupported cast: {0} to {1}")]
    UnsupportedCast(DataType, DataType),

    #[error("Casting to {0} out of range")]
    CastOutOfRange(&'static str),

    #[error("Numeric out of range")]
    NumericOutOfRange,

    #[error("Numeric out of range: underflow")]
    NumericUnderflow,

    #[error("Numeric out of range: overflow")]
    NumericOverflow,

    #[error("Division by zero")]
    DivisionByZero,

    #[error("Parse error: {0}")]
    // TODO(error-handling): should prefer use error types than strings.
    Parse(Box<str>),

    #[error("Invalid parameter {name}: {reason}")]
    // TODO(error-handling): should prefer use error types than strings.
    InvalidParam {

View on GitHub (pinned to 6469eb736d)

Solutions

  1. Widen column/intermediate types (e.g. use larger decimal precision)
  2. Check intermediate arithmetic for potential overflow and reorder operations
  3. Use try_* variants where the API supports it
  4. Validate data ranges before computing

Example fix

// before
SELECT a * b AS c FROM t; -- overflows decimal(38)
// after
SELECT (a::decimal(38, 4) * b)::decimal(38, 10) AS c FROM t;
Defensive patterns

Strategy: validation

Validate before calling

// pre-check numeric bounds before arithmetic
debug_assert!(acc.checked_mul(x).is_some(), "intermediate would overflow");

Try / catch

match expr.eval(batch).await {
    Err(e) if e.to_string().contains("Numeric out of range") => {
        // widen types and retry the computation
    }
    r => r,
}

Prevention

When it happens

Trigger: Arithmetic like a numeric multiplication overflowing decimal precision, or a cast whose overflow path maps to the generic variant.

Common situations: Aggregations over very large numbers exceeding decimal(38) precision; multiplication of big integers; upstream data growing beyond assumed bounds.

Understand the failure class

Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.

Related errors


AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11). Data as JSON: /api/errors/8c28d8c2c2f08b0d. Report an issue: GitHub.