Community
Participate
Working Groups
Someone writing a new service might need to add new error codes. Currently error codes are defined in errors.h file. There is no error code definitions in Java or docs. A method of adding new error codes needs to be defined and documented.
This was discussed in power.org discussions. There is an additional problem that there is no interoperability of implementations in terms of well-defined error codes and an error code format. This problem was broken down into three distinct areas: - Standardizing the error codes with specific levels of detail - Determining a language neutral method for specifying error objects (avoid Java-centric typing / marshalling) - Allowance for chaining errors (traceback) A consensus proposal was created for the error codes issue. This proposal requires elaboration and development. An error code shall encode the following information in an integer-based type: 1. The severity of the error, covering at least the following levels: warning, localized error (affecting the operation), fatal error 2. A general error type (e.g. access / privilege, out of range, parameter, syntax, etc.) 3. An error sub-type, where the following applies The sub-type consists of three separate ranges of values. The common error types for the framework. The definitions of these will be based on POSIX errno definitions, except that the specification shall fix specific values for them. The second range of values are values specific to the individual service(s). The third range consists of vendor-specific values (only one vendor-specific value is required). Wherever vendor-specific error codes are used, the client will make no attempt to resolve potential collisions between different vendors or disambiguate to try to determine which vendor's service generated the error. Instead, the error object will be modified according to some convention to identify the source (i.e. vendor service) of the error and codify the reason for the error. The priority of this should be raised to ensure that the first revision of the power.org contains a useable specification of error codes.
Proposed specification - Change TCF from using both a code and string arguments to only having one argument that is either an empty string (single null character), or a JSON object - Empty means no error - Object contains the following fields - "Code" <int> - "Format" <string> - 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> - "Severity" <int> - 0 - error (default) - 1 - warning - 2 - fatal - "AltCode" <int> - 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> - All fields except "Code" are optional - Code ranges - 0x0-0xffff Standard TCF codes - Includes a limited subset of POSIX errors - OTHER - can be used together with "AltCode" - 0x10000-0x1ffff Service specific codes - 0x20000-0x2ffff Reserved codes - will never be used by the TCF standard - 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".
I assume that separating "format" from "params" is in order to support translation into foreign languages by means of String lookup? Or also in order to save the processing power of doing String substitution on the agent, and perform the substitution on the final client instead? The notion of "optional fields" should be clarified. E.g. is it allowed to have an AltCode but no AltOrg -- I'd assume no. Or, is it allowed to have Params but no MessageFormat -- I'd assume yes, since for the well-known standardized TCF error codes the proper Format should be well-defined as well such that only the client needs to know it. Also, there could be a "message format providing value-add" which runs on the client, and adds the Format Strings for the plain error codes sent from the agent. I'd suggest adding a timestamp to the error. In analyzing error logs, it has often proved extremely useful to see those timestamps in order to understand how errors are interrelated, or just to have an idea of what action had been performed at the time the error was issued. I'd also suggest adding a "source" field to the error, which would be the TCF service issuing the error. Timestamp and Source fields are probably on a different layer than the error object itself?
I have committed changes as discussed, including fields for timestamp and service name as per Martin comment. Both TCF code and documentation are updated.
Moving bugs to new home for IP log.
Bulk change: Marking all bugs from the TM era (until June 2011) target 0.3
