Handling errors

When handling errors, the most important exception to catch is the DKException class.

Do not use exceptions for program logic, and do not rely on catching exceptions to detect if something exists in the content server or for any reason other than for truly exceptional cases. Using exceptions in program logic decreases performance and can render tracing and log information useless for debugging and support.

Carefully review all of the exception information. There are numerous sub-classes of DKException and depending on the program, it might be best to handle each exception individually. The following table contains DKException information.

Table 1. DKException information
DKException Description
Name Exception Class Name. Contains subclass name.
Message A specific message explains the error. The message can contain a lot of information, sometimes encapsulating important variable states at the time the error was detected.
Message ID A unique Message ID identifies this error type and matches it to the core message.
Error State Might contain additional error information about the state of the OO API or library server error. If the library server detects an error, the following four pieces of information are packaged here:
  • Return code
  • Reason code
  • Ext / SQL return code
  • Ext / SQL reason code
Error Code Might contain the library server return code.
Stack Trace Important information indicating the failure point in the user program and exactly where the error was last detected or handled by the OOAPI.

When working in Java™, you must also handle the java.lang.Exception. For an example of catching and printing errors, see the SConnectDisconnectICM sample in the samples directory.