TrackerHub
  1. Docs
TrackerHub
  • Docs
    • 01. Project Overview
    • 02. Authentication
    • 03. Error Handling
    • 04. Input Operations
    • 05. GPS Position Workflow
  • API
    • Device Type
      • Device Type
    • Tracker
      • Tracker
      • Tracker
      • Tracker
      • Tracker
    • Device
      • Create Device
      • List Device
      • Device
      • Device
      • Device
    • Position
      • Position
      • Position
      • Position
      • Create Position
      • Position :vendor
      • latest-position
      • latest-positions
      • latest-positions :deviceId
    • Configuration
      • Config
      • Config
      • Config
      • Config
    • Healthcheck
      GET
  1. Docs

03. Error Handling

Business Errors#

The error-handling system is designed to provide standardized and informative messages about business and validation errors. This mechanism manages specific errors (such as data conflicts or missing resources) and explains the reason for the error.
Validation Errors: These occur when invalid data is entered into certain fields. For example, entering a phone number in a field that requires a valid email address.
Resource Errors: These are related to invalid parameters, invalid operations, existing or non-existent entities, etc. For example, attempting to add a device with data that already belongs to an existing device.
A list of validation and resource errors is provided in the following section

Validation Errors#

The validation error is also standardized and provides customized messages for such errors within the system. It maps validation issues identified in input fields.
Most possible errors are predefined. Examples include:
ARRAY_MUST_NOT_BE_EMPTY: The array field must not be empty.
FIELD_MAX_LENGTH_EXCEEDED: The field has exceeded the maximum character limit.
FIELD_MUST_BE_INTEGER: The field must contain an integer.
Each error code is represented by a constant and mapped to a specific message, ensuring uniformity and standardization.
By default, the error message includes the field containing the invalid data and, when applicable, the expected format for that specific case.
Most validation messages follow this format, with some exceptions:
"Field {dataField} must be {fieldValidation}"
For example, in a registration context, if an email is not in the expected format, such as "123456789" entered in some email field, the expected error message would be:
"Field 123456789 must be a valid email"
This message specifies that the input does not conform to the required email format, and would return the following response body:
{
  "status": "error",
  "error": {
    "error_code": "INVALID_EMAIL_FORMAT",
    "message": "Field 123456789 must be a valid email",
    "field": "email"
  }
}

List of Validation Errors#

Error CodeDescriptionExample of Returned Message
ARRAY_MUST_NOT_BE_EMPTYThe array must not be emptyField {fieldName} must not be empty
FIELD_MAX_LENGTH_EXCEEDEDThe field exceeds the maximum character limitField {fieldName} must have at most {maxLength} characters
FIELD_MIN_LENGTH_NOT_METThe field does not meet the minimum character limitField {fieldName} must have at least {minLength} characters
FIELD_MUST_BE_BOOLEANThe field must be a boolean valueField {fieldName} must be a boolean
FIELD_MUST_BE_EMAILThe field must contain a valid emailField {fieldName} must be a valid email
FIELD_MUST_BE_INTEGERThe field must be an integerField {fieldName} must be an integer
FIELD_MUST_BE_NUMERICThe field must be a numberField {fieldName} must be a number
FIELD_MUST_BE_PHONE_NUMBERThe field must contain a valid phone numberField {fieldName} must be a valid phone number
FIELD_MUST_BE_STRINGThe field must be a stringField {fieldName} must be a string
FIELD_MUST_NOT_BE_EMPTYThe field must not be emptyField {fieldName} must not be empty
INVALID_DATE_FORMATThe field must contain a valid date in the specified formatField {fieldName} must be a valid date string in the format {dateFormat}
INVALID_URL_FORMATThe field must contain a valid URLField {fieldName} must be a valid URL
NUMBER_MUST_BE_POSITIVEThe field must be a positive numberField {fieldName} must be a positive number
UNSUPPORTED_ENUM_VALUEThe field must contain a valid value from the allowed setField {fieldName} must be one of the following enum values: {enumValues}
VALUE_ABOVE_MAXIMUMThe field value exceeds the maximum allowed limitValue of field {fieldName} is above the maximum allowed ({maxValue})
VALUE_BELOW_MINIMUMThe field value is below the minimum allowed limitValue of field {fieldName} is below the minimum allowed ({minValue})
FIELD_MUST_BE_ARRAYThe field must be an arrayField {fieldName} must be an array
FIELD_MUST_BE_UUIDThe field must contain a valid UUIDField {fieldName} must be a valid UUID
FIELD_MUST_BE_DEFINEDThe field must be definedField {fieldName} must be defined

Resource Errors#

Resource errors are similarly standardized and provide customized messages to indicate conflicts or issues with existing resources in the system. These errors occur when operations cannot be completed due to conflicts, missing resources, or other resource-related constraints.
Each error code is represented by a constant and mapped to a specific message, ensuring uniformity and clarity.
By default, the error message identifies the resource or field causing the issue and provides additional context about the nature of the conflict or error.
Most resource error messages follow a format similar to this:
"{Entity} already exists with this {Field}"
For example if a client attempts to create a tracker with an IMEI that already exists in the system, the expected conflict error message would be:
"TRACKER already exists with this IMEI""
The response body would return the following:
{
    "status": "error",
    "error": {
        "error_code": "ENTITY_WITH_FIELD_ALREADY_EXISTS",
        "message": "TRACKER already exists with this IMEI",
        "details": {
            "field": "TRAKCER",
            "value": {
                "trackerName": "tracker test",
                "trackerDesc": "tracker description",
                "imei": "123-ABC-4567",
                "status": "active"
            }
        }
    }
}

Request Response Codes#

CodeDescription
200Operation completed successfully.
201Creation completed successfully.
400Error in request parameters or entity not found.
401User not authorized or not logged in.
409Conflict with an existing entity or relationship.
422Issue with parameters in the database request.
500Other errors.

List of Resource Errors#

Error CodeDescriptionHTTP Status Code
INVALID_PARAMETERSThere were one or more validation errors in the request400 Bad Request
ENTITY_WITH_FIELD_ALREADY_EXISTS{entity} already exists with this {field}409 Conflict
ENTITY_WITH_FIELD_NOT_FOUND{entity} not found with field {field}400 Bad Request
FIELD_MUST_BE_OF_TYPE{field} must be of type {type}400 Bad Request
FIELD_MUST_NOT_BE_EMPTY{field} must not be empty400 Bad Request
INSTANCE_NOT_FOUNDInstance not found400 Bad Request
ENTITY_NOT_FOUND{entityName} {entity} not found400 Bad Request
ENTITY_ALREADY_EXISTS{entityName} already exists409 Conflict
QUERY_FAILEDDatabase query error occurred422 Unprocessable Entity
REQUEST_FAILEDError processing request500 Internal Server Error
Previous
02. Authentication
Next
04. Input Operations