LuciferYang opened a new pull request, #57604:
URL: https://github.com/apache/spark/pull/57604

   ### What changes were proposed in this pull request?
   
   This PR proposes to assign a proper error condition for the legacy error 
conditions `_LEGACY_ERROR_TEMP_3201`, `_3202`, `_3203`, `_3204` and `_3205`, 
which are all thrown from the constructor of `ExpressionInfo` when the 
`@ExpressionDescription` annotation metadata of an expression is malformed.
   
   The five legacy conditions are folded into a single umbrella condition 
`MALFORMED_EXPRESSION_INFO` with five subclasses, one per validated field:
   
   | Legacy | New condition | Field |
   |---|---|---|
   | `_LEGACY_ERROR_TEMP_3201` | `MALFORMED_EXPRESSION_INFO.NOTE` | `note` |
   | `_LEGACY_ERROR_TEMP_3202` | `MALFORMED_EXPRESSION_INFO.GROUP` | `group` |
   | `_LEGACY_ERROR_TEMP_3203` | `MALFORMED_EXPRESSION_INFO.SOURCE` | `source` |
   | `_LEGACY_ERROR_TEMP_3204` | `MALFORMED_EXPRESSION_INFO.SINCE` | `since` |
   | `_LEGACY_ERROR_TEMP_3205` | `MALFORMED_EXPRESSION_INFO.DEPRECATED` | 
`deprecated` |
   
   The shared umbrella message names the offending field and expression 
(`'<fieldName>' is malformed in the expression [<exprName>]:`), and each 
subclass carries the field-specific detail. The assigned SQLSTATE is `22023` 
(invalid parameter value), consistent with the sibling `MALFORMED_*` conditions 
that validate a value against an allowed set or format 
(`MALFORMED_RECORD_IN_PARSING`, `MALFORMED_VARIANT`, and the 
`INVALID_PARAMETER_VALUE` archetype all use `22023`).
   
   ### Why are the changes needed?
   
   `_LEGACY_ERROR_TEMP_*` conditions are placeholders that should be replaced 
with proper, named error conditions per the guideline in 
`common/utils/src/main/resources/error/README.md`. This is part of the ongoing 
effort to migrate legacy error conditions to the structured error framework.
   
   ### Does this PR introduce _any_ user-facing change?
   
   No. These conditions are thrown only when a built-in/UDF expression ships a 
malformed `@ExpressionDescription` annotation, which is a developer-facing 
invariant rather than an end-user query error. The error message wording is 
essentially preserved; only the condition name and SQLSTATE change.
   
   ### How was this patch tested?
   
   Updated the existing assertions in `ExpressionInfoSuite` to check the new 
conditions and parameters, and ran:
   - `ExpressionInfoSuite` - 10/10 passed
   - `SparkThrowableSuite` - 34/34 passed (JSON validity, alphabetical 
ordering, mandatory SQLSTATE, round-trip)
   
   ### Was this patch authored or co-authored using generative AI tooling?
   
   Generated-by: Claude Code (Opus 4.8)
   


-- 
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.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to