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: [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]
