Error Data Types
Error details are transferred to the client using a generic error structure, which is returned instead of the actual response structure.
|Schema location (Source)||https://route.api.here.com/routing/7.2/xsd/LBSP-Routing-Errors.xsd|
The error type defines the following attributes:
| || |
Errors are categorized into one of the following groups:
| ||Defined name of the concrete error, such as "InvalidInputData" or "ExceededUsageLimit".|
| ||Clear text error message|
| ||Arbitrary value to trace back the request. This value is copied from the request which caused the error.|
| ||Generic container to include structured details regarding the error. Each concrete error sub type defines the semantics of the values in the container.|
| || |
Provides details about the request itself, such as the time at which it was processed, a request id, or the map version on which the calculation was based.
Errors are returned in the same format (XML, JSON, JSONP) as the expected response.
The error type name is mapped to the
ServiceError.type attribute. Services may define their own, more specific errors based on these three error types. The name of the more specific error type is then mapped to the
However, the basic error types may also be used for concrete errors if there is no sub type that better fits the error situation. In that case, the
ServiceError.subtype attribute is omitted.
The usage of the ServiceError.AdditionalData element is not defined for the basic error types. Error sub types may define their own values.