Error Handling Deep Dive

Error handling is structured. All errors should be expected and they are all defined in with instructions what to do when such an error happens.

Limitations

Not everything can be covered by warnings due to technical reasons – the warning manager itself needs some data to be initialized. There are two groups of deployment issues which are not configurable – they raise an exception which is not caught:

  1. Missing libraries required for Price Setting Package to run:

    1. PriceBuilderCommonElementUtils

    2. PriceListManagement

    3. SharedLib

  2. Missing company parameters:

    1. PriceSettingConfig

    2. DependencyConfiguration

    3. DependencyMappingConfig

    4. WarningConfig

Unexpected Errors

These are also two steps for "default" exceptions in case something unexpected happens:

  1. "UNEXPECTED_ERROR" entry in the . This is manageable by users but we strongly recommend to set it to "Critical, Yes, Yes" and report every occurrence of such an error. When this error is used, it has a modified message to help track what went wrong.

  2. Undefined behavior is specified in the code and it has the following code: "NO_ERROR_DEFINED".

Abortable Errors

There is a group of errors that tells us that there is no point in doing any further calculations. We would not be able to get any valid results either way, so we abort the calculation instead of passing on wrong/missing data/configurations. The calculation is aborted on a module-level, so only elements in the module that raised one of these errors are skipped.

The list of abortable error types:

  • VALIDATION

  • MODULE_UNUSABLE

  • NO_CONFIG

  • EMPTY_CONFIG

Â