ToSparkExpression converts both interval literals into Spark's physical carrier and leans on Math's exact operations to refuse a value that does not fit:
visit(IntervalDayLiteral) folds days, seconds and subseconds into a micros Long. It overflows from roughly 106.7M days, well inside int32, so an out-of-range producer reaches it.visit(IntervalYearLiteral) folds years and months into a months Int. It overflows once the flattened total leaves Int.
Both let the raw java.lang.ArithmeticException escape — long overflow or integer overflow. Neither message says which literal failed, what the component values were, or what the carrier's range is, so a producer emitting an out-of-range interval gets a message that could have come from anywhere in the conversion.
Util.toMicroseconds already sets the module's bar here: it throws UnsupportedOperationException naming the offending precision and the legal bounds. Both interval paths should do the same — bounds-check first, or catch the exact-op failure — and report the components alongside the carrier limit.
Worth doing for the two paths together rather than one at a time, so the two literals keep taking the same stance on the same arithmetic. Raised in review of #1140, which left both bare deliberately for that reason.
ToSparkExpressionconverts both interval literals into Spark's physical carrier and leans onMath's exact operations to refuse a value that does not fit:visit(IntervalDayLiteral)folds days, seconds and subseconds into a microsLong. It overflows from roughly 106.7M days, well insideint32, so an out-of-range producer reaches it.visit(IntervalYearLiteral)folds years and months into a monthsInt. It overflows once the flattened total leavesInt.Both let the raw
java.lang.ArithmeticExceptionescape —long overfloworinteger overflow. Neither message says which literal failed, what the component values were, or what the carrier's range is, so a producer emitting an out-of-range interval gets a message that could have come from anywhere in the conversion.Util.toMicrosecondsalready sets the module's bar here: it throwsUnsupportedOperationExceptionnaming the offending precision and the legal bounds. Both interval paths should do the same — bounds-check first, or catch the exact-op failure — and report the components alongside the carrier limit.Worth doing for the two paths together rather than one at a time, so the two literals keep taking the same stance on the same arithmetic. Raised in review of #1140, which left both bare deliberately for that reason.