There are three ways to use these classes:
- Using an existing exception class.
- Creating a child class that extends ApplicationException.
- Wrapping an exception in an existing application exception.
Although the exception classes themselves are not serializable, they can be converted to ErrorDescriptions, which are serializable in one language, transferred to the receiving side, and deserialized in another language. After deserialization, the initial exception class can be restored.
When transferring an exception from one language to another, the exception type that is closest to the initial exception type is chosen from the exceptions available in the target language.
Defines a base class to defive various application exceptions. Most languages have own definition of base exception (error) types. However, this class is implemented symmetrically in all languages supported by PipServices toolkit. It allows to create portable implementations and support proper error propagation in microservices calls.
Factory to recreate exceptions from ErrorDescription values passed through the wire.
Errors due to improper user requests. For example: missing or incorrect parameters.
Errors related to mistakes in the microservice’s user-defined configurations.
Errors raised by conflicts between object versions that were posted by the user and those that are stored on the server.
Errors that occur during connections to remote services. They can be related to misconfiguration, network issues, or the remote service itself.
Defines standard error categories supported by PipServices toolkit.
Serializeable error description. It is use to pass information about errors between microservices implemented in different languages. On the receiving side ErrorDescription is used to recreate exception object close to its original type without missing additional details.
Factory used to create serializeable ErrorDescription from ApplicationException or from arbitrary errors. The ErrorDescriptions are used to pass errors through the wire between microservices implemented in different languages. They allow to restore exceptions on the receiving side close to the original type and preserve additional information.
A helper class to parameters from “options” configuration section.
Errors caused by programming mistakes.
Errors related to calling operations, which require the component to be in a specific state. For instance: business calls when the component is not ready.
Errors returned by remote services or by the network during call attempts.
Errors caused by attempts to access missing objects.
Access errors caused by missing user identity (authentication error) or incorrect security permissions (authorization error).
Unknown or unexpected errors.
Errors caused by calls to unsupported or not yet implemented functionality.