Error Report Format

Copyright (c) 2007-2019 Wind River Systems, Inc. and others. Made available under the EPL 2.0
Agent portion made available under your choice of EPL 2.0 or EDL v1.0 dual-license.

Direct comments, questions to the tcf-dev@eclipse.org mailing list

Table of Contents

• Version History
• Error Report Format

Version History

Error Report Format

TCF standard services use same format for error reporting:

<error report>
    ⇒
    ⇒ null
    ⇒ <object: error description>

Error reports use JSON for message encoding, see JSON - Preferred Marshaling.

Empty or null error report means success. Error description provides error details, including error code and a short, localizable, human readable explanation of the error.

Error description properties are:

"Code" : <integer>

Error code. Can belong to one of predefined ranges:

• 0x0-0xffff Standard TCF codes, includes a limited subset of POSIX errors, and OTHER error code, which can be used together with "AltCode"
• 0x10000-0x1ffff Service specific codes
• 0x20000-0x2ffff Reserved codes - will never be used by the TCF standard

"Time" : <integer>

Error timestamp, in milliseconds since midnight, January 1, 1970 UTC

"Service" : <string>

Name of the service that reported the error. Required when "Code" is service specific code.

"Format" : <string>

Error description format supports separation between constant and variable parts of error message ("Format" and "Params"). This is done to support localization. Format string is expected to allow translation into foreign languages by means of string table lookup. The format string syntax is defined in the Java language library java.text.MessageFormat. In order to simplify clients written in other languages, only a subset of the syntax is supported:

• Supported format types: (none), number
• Supported format styles:
  • number: (none), "integer", "percent"

"Params" : <array>

An array of values to be used together with "Format" to create the error message.

"Severity" : <integer>

Predefined severity values:

• 0 - error (default)
• 1 - warning
• 2 - fatal

"AltCode" : <integer>

Alternative error code. This can be used to represent, for example, OS, POSIX, or other vendor specific error codes

"AltOrg" : <string>

ID of organization defining "AltCode", for example "Linux", "VxWorks", "Wind River", etc

"CausedBy" : <object: error description>

A nested error description. Can be used to describe a root cause of this error.

All fields except "Code" are optional.

Standard error codes:

    OTHER               = 1
    JSON_SYNTAX         = 2
    PROTOCOL            = 3
    BUFFER_OVERFLOW     = 4
    CHANNEL_CLOSED      = 5
    COMMAND_CANCELLED   = 6
    UNKNOWN_PEER        = 7
    BASE64              = 8
    EOF                 = 9
    ALREADY_STOPPED     = 10
    ALREADY_EXITED      = 11
    ALREADY_RUNNING     = 12
    ALREADY_ATTACHED    = 13
    IS_RUNNING          = 14
    INV_DATA_SIZE       = 15
    INV_CONTEXT         = 16
    INV_ADDRESS         = 17
    INV_EXPRESSION      = 18
    INV_FORMAT          = 19
    INV_NUMBER          = 20
    INV_DWARF           = 21
    SYM_NOT_FOUND       = 22
    UNSUPPORTED         = 23
    INV_DATA_TYPE       = 24
    INV_COMMAND         = 25

Service specific error code definitions, if any, are part of service specfications. Standard and service specific error codes can be extended over time. A client that does not recognize a specific error code should treat it in the same way as "OTHER".

For encoding of <object>, <string>, etc., see JSON - Preferred Marshaling.