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