[SPARK-47429][SQL] Rename error class to condition

common/utils/src/main/java/org/apache/spark/SparkThrowable.java

@@ -27,16 +27,16 @@
  *
  * - For backwards compatibility, existing Throwable types can be thrown with an arbitrary error
  *   message with a null error class. See [[SparkException]].
- * - To promote standardization, Throwables should be thrown with an error class and message
+ * - To promote standardization, Throwables should be thrown with an error condition and message
  *   parameters to construct an error message with SparkThrowableHelper.getMessage(). New Throwable
  *   types should not accept arbitrary error messages. See [[SparkArithmeticException]].
  *
  * @since 3.2.0
  */
 @Evolving
 public interface SparkThrowable {
-  // Succinct, human-readable, unique, and consistent representation of the error category
-  // If null, error class is not set
+  // Succinct, human-readable, unique, and consistent representation of the error condition.
+  // If null, error condition is not set.
   String getErrorClass();
 
   // Portable error identifier across SQL engines

common/utils/src/main/resources/error/README.md

@@ -39,7 +39,7 @@ The terms error class, state, and condition come from the SQL standard.
 
 Unfortunately, we have historically used the term "error class" inconsistently to refer both to a proper error class like `42` and also to an error condition like `DATATYPE_MISSING_SIZE`.
 
-Fixing this will require renaming `SparkException.errorClass` to `SparkException.errorCondition` and making similar changes to `ErrorClassesJsonReader` and other parts of the codebase. We will address this in [SPARK-47429]. Until that is complete, we will have to live with the fact that a string like `DATATYPE_MISSING_SIZE` is called an "error condition" in our user-facing documentation but an "error class" in the code.
+Fixing this will require renaming `SparkException.errorClass` to `SparkException.errorCondition` and making similar changes to other parts of the codebase. We will address this in [SPARK-47429]. Until that is complete, we will have to live with the fact that a string like `DATATYPE_MISSING_SIZE` is called an "error condition" in our user-facing documentation but an "error class" in the code.
 
 For more details, please see [SPARK-46810].