MaxGekk commented on a change in pull request #31840:
URL: https://github.com/apache/spark/pull/31840#discussion_r594533710
##########
File path: sql/catalyst/src/main/scala/org/apache/spark/sql/types/numerics.scala
##########
@@ -26,7 +26,7 @@ import org.apache.spark.sql.types.Decimal.DecimalIsConflicted
private[sql] object ByteExactNumeric extends ByteIsIntegral with
Ordering.ByteOrdering {
private def checkOverflow(res: Int, x: Byte, y: Byte, op: String): Unit = {
if (res > Byte.MaxValue || res < Byte.MinValue) {
- throw new ArithmeticException(s"$x $op $y caused overflow.")
Review comment:
Actually, we have > 100 places where we use `*Exact` methods from the
standard library. Such methods just throw the exception w/o any clues about
inputs:
```java
public static int multiplyExact(int x, int y) {
long r = (long)x * (long)y;
if ((int)r != r) {
throw new ArithmeticException("integer overflow");
}
return (int)r;
}
```
As the first step, we could align our `ArithmeticException` to the standard
library (just a few places). After that we can think of how we can improve such
kind of exceptions in all possible places in Spark, and give users more context.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
