f31cf163d9
### What changes were proposed in this pull request?
Refactors the base Throwable trait `SparkError.scala` (introduced in SPARK-34920) an interface `SparkThrowable.java`.
### Why are the changes needed?
- Renaming `SparkError` to `SparkThrowable` better reflect sthat this is the base interface for both `Exception` and `Error`
- Migrating to Java maximizes its extensibility
### Does this PR introduce _any_ user-facing change?
Yes; the base trait has been renamed and the accessor methods have changed (eg. `sqlState` -> `getSqlState()`).
### How was this patch tested?
Unit tests.
Closes #33164 from karenfeng/SPARK-35958.
Authored-by: Karen Feng <karen.feng@databricks.com>
Signed-off-by: Wenchen Fan <wenchen@databricks.com>
(cherry picked from commit 71c086eb87
)
Signed-off-by: Wenchen Fan <wenchen@databricks.com>
49 lines
2.8 KiB
Plaintext
49 lines
2.8 KiB
Plaintext
<!--
|
|
Thanks for sending a pull request! Here are some tips for you:
|
|
1. If this is your first time, please read our contributor guidelines: https://spark.apache.org/contributing.html
|
|
2. Ensure you have added or run the appropriate tests for your PR: https://spark.apache.org/developer-tools.html
|
|
3. If the PR is unfinished, add '[WIP]' in your PR title, e.g., '[WIP][SPARK-XXXX] Your PR title ...'.
|
|
4. Be sure to keep the PR description updated to reflect all changes.
|
|
5. Please write your PR title to summarize what this PR proposes.
|
|
6. If possible, provide a concise example to reproduce the issue for a faster review.
|
|
7. If you want to add a new configuration, please read the guideline first for naming configurations in
|
|
'core/src/main/scala/org/apache/spark/internal/config/ConfigEntry.scala'.
|
|
8. If you want to add or modify an error type or message, please read the guideline first in
|
|
'core/src/main/resources/error/README.md'.
|
|
-->
|
|
|
|
### What changes were proposed in this pull request?
|
|
<!--
|
|
Please clarify what changes you are proposing. The purpose of this section is to outline the changes and how this PR fixes the issue.
|
|
If possible, please consider writing useful notes for better and faster reviews in your PR. See the examples below.
|
|
1. If you refactor some codes with changing classes, showing the class hierarchy will help reviewers.
|
|
2. If you fix some SQL features, you can provide some references of other DBMSes.
|
|
3. If there is design documentation, please add the link.
|
|
4. If there is a discussion in the mailing list, please add the link.
|
|
-->
|
|
|
|
|
|
### Why are the changes needed?
|
|
<!--
|
|
Please clarify why the changes are needed. For instance,
|
|
1. If you propose a new API, clarify the use case for a new API.
|
|
2. If you fix a bug, you can clarify why it is a bug.
|
|
-->
|
|
|
|
|
|
### Does this PR introduce _any_ user-facing change?
|
|
<!--
|
|
Note that it means *any* user-facing change including all aspects such as the documentation fix.
|
|
If yes, please clarify the previous behavior and the change this PR proposes - provide the console output, description and/or an example to show the behavior difference if possible.
|
|
If possible, please also clarify if this is a user-facing change compared to the released Spark versions or within the unreleased branches such as master.
|
|
If no, write 'No'.
|
|
-->
|
|
|
|
|
|
### How was this patch tested?
|
|
<!--
|
|
If tests were added, say they were added here. Please make sure to add some test cases that check the changes thoroughly including negative and positive cases if possible.
|
|
If it was tested in a way different from regular unit tests, please clarify how you tested step by step, ideally copy and paste-able, so that other reviewers can test and check, and descendants can verify in the future.
|
|
If tests were not added, please describe why they were not added and/or why it was difficult to add.
|
|
-->
|