[GitHub] [druid] paul-rogers commented on issue #13123: Enhanced Druid Exceptions for improved user error messages

["paul-rogers (via GitHub)" <gi...@apache.org>]

paul-rogers commented on issue #13123:
URL: https://github.com/apache/druid/issues/13123#issuecomment-1450525821

   After some discussion, here is an alternative approach to satisfy some additional requirements. This is primarily for discussion to help brainstorm a solution.
   
   * Error messages must be localizable: not so much for language, as to use terminology consistent with a deployment or to redact information not appropriate in a given context.
   * Every error must have a unique error code (also required to enable the message catalog).
   
   Given this, we propose that all errors have a unique text error code. We can standardize around a pattern such as "SQL" + "Validation" + "SpecificError" or "MSQ" + "IO" + "SpecificError". Error codes form a hierarchy.
   
   Each error provides a set of named parameters that are interpolated into the error text. For example:
   
   ```text
   Code: ['SQL'. 'Validation', 'ColumNotFound']
   Column: foo
   Line: 4
   Position: 3
   ID: 0000-1111-2222...
   ```
   
   Each error instance is given a unique UUID to allow system operators to find the specific error instance in logs that users saw in a UI.
   
   Then, the message catalog can have a variety of messages depending on the level of detail appropriate to given deployment:
   
   For example, for out-of-the-box Druid:
   
   ```text
   Line [{Line}], Column [{Position]]: Column [{Column}] was not found in any table in the query.
   ```
   
   For a deployment when the front end allows the user to select columns, but not edit the SQL:
   
   ```text
   No such column [{Column}]
   ```
   
   For a deployment where the SQL queries are hard-coded, power a dashboard, and only a development team can modify the SQL. The error indicates a bug in the application:
   
   ```text
   Invalid SQL: contact Support. Case {ID}
   ```
   
   To make this work, each application would be a subclass of a `DruidException` which has a set of attributes, but not a message:
   
   * Error code
   * Event ID
   * Parameters, as fields on the class
   
   The text of each message is given in message catalog, represented as a properties file following the Java I18N pattern. For example, for the stock `druid.properties`:
   
   ```text
   SQLValidationColumNotFound=Line [{Line}], Column [{Position]]: Column [{Column}] was not found in any table in the query.
   ```
   
   Each deployment can provide a custom file. The file overrides the standard Druid messages. Messages not defined in the override catalog use the Druid version. For example for a deployment for ABC Co., define `abc.properties`:
   
   ```text
   SQLValidationColumNotFound=No such column [{Column}]
   ```
   
   Each exception can be logged. Logging can be set up based on the code hierarchy. For example, on out-of-the-box Druid, SQL errors might not be logged because they are directed at users. Other sites may choose to log everything. Logging of errors uses a site-defined format. Options may include:
   
   * Include the ID or not.
   * Include the error code or not.
   * Use message or individual fields instead.
   
   For backward compatibility, out-of-the-box may log the error messages formatted from the catalog. Other sides may want messages of the form:
   
   ```text
   {ID} {Code} {Params}
   ```
   
   Example:
   
   ```text
   0000-1111-2222...: SQL-Validation-ColumNotFound - Line: 4, Position: 3, Column: 'foo'
   ```
   
   To make the above work, every exception is a subclass of `DruidException`. Each class can represent one or more error codes. The exception includes parameters as fields. The class is Jackson-serializable so it can be passed between nodes. The class provides metadata about the error, the field serialization order for logs, etc.
   


-- 
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: commits-unsubscribe@druid.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org