[SPARK-46393][SQL] Classify exceptions in the JDBC table catalog

[MaxGekk]

What changes were proposed in this pull request?

In the PR, I propose to handle exceptions from JDBC drivers in the JDBC table catalog, classify them and converted to appropriate Spark exception w/ an error class. This PR covers the following functions where such errors haven't been classified yet:

• list tables
• namespace exists
• list namespaces

Why are the changes needed?

To unify Spark exceptions, and migrate onto new error framework.

Does this PR introduce any user-facing change?

Yes, if user code expects that Spark SQL bypass Java exceptions from JDBC drivers.

How was this patch tested?

By existing test suites:

$ build/sbt "test:testOnly *JDBCV2Suite"
$ build/sbt "test:testOnly *JDBCTableCatalogSuite"

Was this patch authored or co-authored using generative AI tooling?

No.

[srielau]

@MaxGekk
Is this just doing:
/**

• Gets a dialect exception, classifies it and wraps it by AnalysisException.
• @param message The error message to be placed to the returned exception.
• @param e The dialect specific exception.
• @return AnalysisException or its sub-class.
  */
  def classifyException(message: String, e: Throwable): AnalysisException = {
  new AnalysisException(
  errorClass = "_LEGACY_ERROR_TEMP_3064",
  messageParameters = Map("msg" -> message),
  cause = Some(e))
  }

Shouldn't we raise proper error classes instead of hiding behind "message"

[cloud-fan]

@srielau This seems like a lot of work as we need to understand different errors from different databases. Shall we have a general error class name as the fallback? Each JDBC dialect can override this method and provide more concrete error classes.

[srielau]

@srielau This seems like a lot of work as we need to understand different errors from different databases. Shall we have a general error class name as the fallback? Each JDBC dialect can override this method and provide more concrete error classes.

I count 8 invocations of classifyException() in this file. Each invocation adds better information using English. Why can't these be error classes?

At a minimum we could give: _LEGACY_ERROR_TEMP_3064 a proper name and each of these invocations picks a subclass.

[MaxGekk]

At a minimum we could give: _LEGACY_ERROR_TEMP_3064 a proper name and each of these invocations picks a subclass.

There are no tests at all for the cases where JDBC op fails. I believe we should go by the regular way: write tests, update docs, assign names, improve error messages, and so.

Let me merge this PR since it fixes obvious holes in the implementation.

[MaxGekk]

Merging to master. Thank you, all for review.

[srielau]

Opened: https://issues.apache.org/jira/browse/SPARK-46410 as follow up.

[MaxGekk]

@srielau @cloud-fan The small PR with assigned names is ready: #44358