Developer Tips & Tricks - Isolating Problematic Entities

By: Shilpa Dhall, Developer

How to process the error information coming from ACIS APIs to isolate problematic entities

An ACIS API returns its status as an outcome object. The success of an API can be assessed by outcome::ok(). A return value of true indicates the success of the API and false indicates its failure.

The failure of the API (either failsafe or non failsafe) is always accompanied with the information of its failure. Sometimes even the success of a failsafe API is accompanied with information of problems it encountered, if any, that may cause the downstream operations to fail if not corrected.

For example, failsafe tolerant stitching API api_stitch proceeds ahead stitching other entities even though it may have encountered invalid topology, registering it as errors encountered. Although api_stitch is successful, downstream operations may fail due to the invalid topology.

How does one get information about the causes of the problems encountered by the API?

The outcome class contains error_info object(s) that can be used to process this error information.

How does one know whether the API has encountered any errors?

The method outcome:: encountered_errors returns true which indicates that the API has encountered errors, either fatal or one or more failsafe errors otherwise it returns false. A failsafe error is an error that a failsafe API encounters during an atomic operation.

How does one get all errors encountered by the API?

The method outcome:: get_error_info_list returns the error_info_list that contains the fatal error or one or more failsafe errors. Each error_info list is a list of objects of error_info class whose base class is error_info_base.

What does this error_info object contain?

Each error_info object gives following information –

For example for every failsafe error encountered, an error_info object with severity SPA_OUTCOME_ERROR is added to the outcome class object

  1. The entities associated with the error_info – ok. So, these are the problematic entities
  2. The error number associated with the error_info – This was the reason why the API could not proceed on the noted entities.
  3. The severity– The severity can be classified as:
    • fatal (SPA_OUTCOME_FATAL)
    • error(SPA_OUTCOME_ERROR)
    • problem(SPA_OUTCOME_PROBLEM)
    • insanity( SPA_OUTCOME_INSANITY)
  4. The reasons – that lead to this error which is again a list of error info objects.

What is the reason of the FAILURE of the API?

The method outcome:: error_number provides the error number of the fatal error due to which the API failed. Use this if the API has failed.

Is there a way to get error information about the FAILURE of the API?

The method outcome:: get_error_info returns the error_info object associated with the fatal error due to which the API failed. The error_info also has an error number associated with it, which is the same as that with which the API failed. Use this if the API has failed.

See example showing error information returned by failsafe api_stitch being processed.

Thus, using the functions of the outcome class and the error_info class, the error information coming out from the ACIS APIs can be processed to isolate problematic entities.

Back to all Winter 2010 Articles

Twitter Facebook LinkedIn YouTube RSS