[
https://issues.apache.org/jira/browse/SPARK-57750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Gekk updated SPARK-57750:
-----------------------------
Affects Version/s: 4.3.0
(was: 5.0.0)
> Assign a name to the error condition _LEGACY_ERROR_TEMP_3084 and set its cause
> ------------------------------------------------------------------------------
>
> Key: SPARK-57750
> URL: https://issues.apache.org/jira/browse/SPARK-57750
> Project: Spark
> Issue Type: Sub-task
> Components: SQL
> Affects Versions: 4.3.0
> Reporter: Max Gekk
> Priority: Major
>
> h3. Summary
> The error condition {{_LEGACY_ERROR_TEMP_3084}} is raised when instantiating
> a Hive UDF/UDAF/UDTF wrapper class fails during function resolution. As part
> of the error-class migration (umbrella SPARK-37935), it should be given a
> proper, descriptive name. In addition, the original failure should be
> attached as the exception {{cause}} rather than only captured as a string.
> h3. Current behavior
> In {{HiveSessionStateBuilder.makeFunctionExpression}}, when building a Hive
> function expression throws, the underlying exception is caught and re-wrapped:
> {code:scala}
> case NonFatal(exception) =>
> val e = exception match {
> case i: InvocationTargetException => i.getCause
> case o => o
> }
> val analysisException = new AnalysisException(
> errorClass = "_LEGACY_ERROR_TEMP_3084",
> messageParameters = Map(
> "clazz" -> clazz.getCanonicalName,
> "e" -> e.toString))
> analysisException.setStackTrace(e.getStackTrace)
> throw analysisException
> {code}
> Two issues:
> * It uses the unnamed legacy condition {{_LEGACY_ERROR_TEMP_3084}} with a
> free-form {{e}} message parameter.
> * The original exception {{e}} is captured only as text ({{e.toString}}) and
> is *not* attached as the cause: the 2-arg {{AnalysisException(errorClass,
> messageParameters)}} constructor sets {{cause = None}}, and the class extends
> {{Exception(message, cause.orNull)}}. As a result {{getCause}} returns
> {{null}}, so callers and tests cannot programmatically unwrap the inner
> failure (for example, asserting the inner condition via {{checkError}}).
> h3. Proposed change
> * Replace {{_LEGACY_ERROR_TEMP_3084}} with a descriptive error condition
> (e.g. a "cannot load/instantiate function class" condition) and proper
> message parameters.
> * Pass the original exception as the cause ({{cause = Some(e)}}) so the inner
> error is preserved on the exception chain.
> * Update affected tests to assert via {{checkError}} on the inner condition
> where appropriate.
> h3. Context
> Found while addressing review feedback on SPARK-57556 (raise a clear error
> for the TIME data type in Hive SerDe interop). A test there wanted to assert
> the inner {{UNSUPPORTED_DATATYPE}} error via {{checkError}}, but because the
> cause is not attached, it had to fall back to substring assertions on the
> wrapped message.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
