Page History

...

• 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 format.

...