Error Handling Deep Dive
Error handling is structured. All errors should be expected and they are all defined in Warning Handling 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:
Missing libraries required for Price Setting Package to run:
PriceBuilderCommonElementUtils
PriceListManagement
SharedLib
Missing company parameters:
PriceSettingConfig
DependencyConfiguration
DependencyMappingConfig
WarningConfig
Unexpected Errors
These are also two steps for "default" exceptions in case something unexpected happens:
"UNEXPECTED_ERROR" entry in the WarningConfig PP. 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.
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
Â