Serge Rielau created SPARK-39416:
------------------------------------
Summary: When raising an exception, pass parameters as a map
instead of an array
Key: SPARK-39416
URL: https://issues.apache.org/jira/browse/SPARK-39416
Project: Spark
Issue Type: Improvement
Components: Spark Core
Affects Versions: 3.3.1
Reporter: Serge Rielau
We have moved away from c-style parameters in error message texts towards
symbolic parameters. E.g.
{code:java}
"CANNOT_CAST_DATATYPE" : {
"message" : [
"Cannot cast <sourceType> to <targetType>."
],
"sqlState" : "22005"
},{code}
{{However when we raise an exception we merely pass a simple array and assume
positional assignment. }}
{{}}
{code:java}
def cannotCastFromNullTypeError(to: DataType): Throwable = {
new SparkException(errorClass = "CANNOT_CAST_DATATYPE",
messageParameters = Array(NullType.typeName, to.typeName), null)
}{code}
This has multiple downsides:
# It's not possible to mention the same parameter twice in an error message.
# When reworking an error message we cannon shuffle parameters without
changing the code
# There is a risk that the error message and the exception go out of synch
unnoticed given we do not want to check for the message text in the code.
So in this PR we propose the following new usage:
{code:java}
def cannotCastFromNullTypeError(to: DataType): Throwable = {
new SparkException(errorClass = "CANNOT_CAST_DATATYPE",
messageParameters = Map("sourceType" -> NullType.typeName, "targetType"
->to.typeName),
context = null)
}{code}
getMessage will then substitute the parameters in the message appropriately.
Moving forward this should be the preferred way to raise exceptions.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org
