• Using features in Telefakt

Error handling

When an error occurs we want to handle it in such a way that it is visible to the user what went wrong, they have a chance to fix it and in the case of a fatal error we collect enough information to debug the error and correct it.

Error handling in Telefakt's backend is done using the DBO.ERROR_INSTANCE_O Database object. It has member procedures to invoke logging and error raising and also methods to output and input JSON and several different constructor methods.

A sample of an invokation of the ERROR_INSTANCE_O would be;

l_error := NEW DBO.ERROR_INSTANCE_O(P_ERROR_NAME => 'requiredParameterNotSupplied', 
    P_OBJECT_TABLE => 'API_ORDS_LOG',P_REMOTE_SYSTEM_ID => l_source_system,
    P_OBJECT_ID => LOG_ID_IN, STRING_REPLACEMENT_ARG_1 =>'relatedparty.role=customer',
    P_API_LOG_ID => LOG_ID_IN);
l_error.raise_rest_api_error(P_API_LOG_ID => LOG_ID_IN);

The parameters are;

  • P_ERROR_NAME - this points to a record in the ERROR_TYPE table which defines and describes the error.
  • P_OBJECT_TABLE - if you don't want to use the default object table defined by the error you can supply a new table new here to overwrite that. The table name is used to link this error to an object.
  • P_OBJECT_ID - to define which instance of the object defined by P_OBJECT_TABLE this error was raised by you supply the primary key of the object table in this parameter.
  • P_REQUEST - in the sample this is left blank, if you have some request input you can put that here, such as the parameters the current running function was called with.
  • P_REMOTE_SYSTEM_ID - outside systems are stored in the SOURCESYSTEMS table, if you know which system made the call the ID of the system should be supplied here.
  • P_API_LOG_ID - if the request which caused your error originated from the API service then a record of that call has been stored in the API_ORDS_LOG table, if you know it you should supply the LOG_ID of the corresponding record to this parameter.
  • STRING_REPLACEMENT_ARG_1 - if the ERROR_NAME supports string replacement (%s is the key tag for that) the replacement string you want to use should be put into this parameter, you can supply up to STRING_REPLACEMENT_ARG_10. If these parameters are used they will be replaced in the REASON and MESSAGE texts of the ERROR_NAME in order, meaning that STRING_REPLACEMENT_ARG_1 will substitute the first replacement text in REASON and MESSAGE, STRING_REPLACEMENT_ARG_2 the next and so on.

We have 7 levels of errors in Telefakt from least important to most important they are;

  • TRACE
  • DEBUG
  • INFO
  • SUCCESS
  • NOTICE
  • WARNING
  • ERROR
  • FATAL

The first three are used for logging and information gathering. SUCCESS is reserved for messages informing about a function of action completing succesfully. NOTICE and WARNING should allow for the action to complete but only if the user confirms that it is OK. ERROR is a hard stop and should not allow for the action to complete, we use this type of fault when we know what went wrong, and can inform the user with some meaningful text FATAL is reserved for unhandled errors where we don't know what went wrong but something has crashed, we want the execution to stop but we don't know what the user needs to do to fix the issue. This is normally an EXCEPTION where we haven't handled a special case, like a duplicate key or no records found. If we study the code we can come up with a meaningfull error for the user, but it was implemented in the first pass. We aim to minimize these types of errors.

Was this page helpful?