You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@spark.apache.org by "Serge Rielau (Jira)" <ji...@apache.org> on 2022/06/08 16:05:00 UTC
[jira] [Updated] (SPARK-39416) When raising an exception, pass parameters as a map instead of an array
[ https://issues.apache.org/jira/browse/SPARK-39416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Serge Rielau updated SPARK-39416:
---------------------------------
Description:
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.
was:
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.
> 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
> Priority: Major
>
> 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-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org