Error-Writing Conventions

• Each error is identified by an error message code and an array of arguments (int, String[]). A combination of a message code and an array of arguments defines a specific error. The array of parameters can be null.

• Each error code is mapped to a short message which is a fixed string and a detailed message which is a template string contains zero or more arguments. Matching is assumed between the number of arguments in the template and the actual number of parameters.

Example of Error Message Code:

10234 may represent an error with the short message:

Connection Error

and the detailed message:

Could not connect via {0} protocol due to timeout of {1} msec

where

{0} = the first argument: a protocol name

{1} = the second argument: the timeout length in msec

Property File Content

A property file should contain two keys for each error message code. For example, for error 45:

• DDM_ERROR_MESSAGE_SHORT_45. Short error description.

• DDM_ERROR_MESSAGE_LONG_45. Long error description (can contain parameters, for example, {0},{1}).

Error Messages Property File

A property file contains a map between an error message code and two messages (short and detailed).

Once a property file is deployed, its data is merged with existing data, that is, new message codes are added while old message codes are overridden.

Infrastructure property files are part of the AutoDiscoveryInfra package.

Locale Naming Conventions

• For the default locale: <file name>.properties.errors

• For a specific locale: <file name>_xx.properties.errors

  where xx is the locale (for example, infraerr_fr.properties.errors or infraerr_en_us.properties.errors).

Error Message Codes

The following error codes are included by default with Universal CMDB. You can add your own error messages to this list.

Error Name	Error Code	Description
Internal	100-199	Mostly resolved from exceptions thrown during Jython script runs
Connection	200-299	Connection failed, no agent on target machine, destination unreachable, and so on
Credential Related	300-399	Permission denied, connection attempt blocked due to a lack of credentials
Timeout	400-499	Time-out during connection/command
Unexpected or Invalid Behavior	500-599	Missing configuration files, unexpected interruptions, and so on
Information Retrieval	600-699	Missing information on target machines, failure querying agent for information, and so on
Resources Related	700-799	Errors relating to out-of-memory or clients not released properly
Parsing	800-899	Error parsing text
Encoding	900	Error in input, unsupported encoding
SQL Related	901-903, 924	Errors received from SQL operations
HTTP Related	904-909	Errors generated during HTTP connections, parsed from HTTP error codes.
Specific Application	910-923	Error reported due to application-specific problems, for example, wrong LSOF version, No Queue Managers found, and so on

Unclassified Content Errors

To support old content without causing a regression, the application and SDK relevant methods handle errors of message code 100 (that is, unclassified script error) differently.

These errors are not grouped (that is, they are not considered as being errors of the same type) by their message code but are grouped by the content of the message. That is, if a script reports an error by the old, deprecated methods (with a message string and without an error code), all messages receive the same error code, but in the application or in the SDK relevant methods, different messages are displayed as different errors.

Changes in Framework

(com.hp.ucmdb.discovery.library.execution.BaseFramework)

The following methods are added to the interface:

• void reportError(int msgCode, String[] params);

• void reportWarning(int msgCode, String[] params);

• void reportFatal(int msgCode, String[] params);

The following old methods are still supported for backward compatibility purposes but are marked as deprecated:

• void reportError(String message);

• void reportWarning (String message);

• void reportFatal (String message);