Errorcode Handling

Here, we need to describe typical checks on errorcodes. In special cases it might be necessary to run checks differently.

The errorcode is always dealt with, if the success of the function depends on further logic. This is especially so, if a positive errorcode represents an OK for the transaction, or when an active response is necessary, such as the issuing of an error message, if an error should occur. Normally, the errorcode is checked for '<= 0'. In a situation, where errorcode > = 0 is not to be dealt with actively, then the errorcode has to be re-activated with 'Reraise'.

The errorcode is to be dealt with for all functions which

• access a directory or file;
• read or write files (even INI files), profiles or codetables; and also
• Post, BlockFill, ConvertBlock, ConvertSwift, DDESetTopic, …

The errorcode is NOT to be dealt with, if the error only refers to programming errors, or a hard technical problem (e.g. database corrupt). Here, a dump is the expressed solution (if the errorcode was not handled).

Functions in which errorcodes are normally not dealt with are:

• Cache* (except for CacheRead),
• All functions which 'only' check arguments for accuracy (ClosePopup, diverse Get functions, diverse Set functions, ResetModified, …)
• All database accesses, except for those mentioned below in 'Special Errorcode Checks'.

Special checks have to be programmed, when errorcodes are set in special situations, where normally the response would be dump. Here, errorcodes have to be re-activated with 'Reraise' for all cases in which errorcodes are not responded to.

Typical functions for special responses include:

These queries should be analog for functions which are derived from them (SDBRead, CacheDBRead, …).