THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- None of the exceptions defined in AsterixDB supports a zero-parameter constructor nor a single string-parameter constructor;
- In all constructors of the root level exception classes, there should be an error code parameter;
- No Usually, no further exceptions should be thrown from constructing an exception for a caught exception that is defined in AsterixDB. Otherwise, the exception handling will be complicated. But there is one outlier scenario, i.e., you want to make end users feel more comfortable with the error messages.
- All message templates should be tested.
Any exceptions that are thrown from the codebase below the
asterixdb
directory should be RuntimeDataException or CompilationException, or their derivatives.- New error messages should not be defined in the source code. Instead, they should live in properties files that map error codes to error messages. Existing error messages that are defined in the source code should be migrated to properties files gradually.
- For error message templates used in the codebase below the
hyracks/algebricks
code base directories, please put their templates into hyracks-fullstack/hyracks/hyracks-api/src/main/resources/errormsg/en.properties. - For error message templates used in the codebase below the
asterixdb
codebase directory, please put their templates into asterixdb/asterix-common/src/main/resources/asx_errormsg/en.properties. - Multiple error codes (using comma to separate them) can be mapped to the same error message templates.
- The text in the two properties files should follow the Java properties file formatformat.
- For error message templates used in the codebase below the
AsterixDB Error code range:
...