09-10-2007 03:59 PM
From reading the documentation, I'm under the impression these macro wrappers are necessary for modeling functions. However, in practice they often appear to be required when simply accessing ACIS data.
It's also my understanding that these wrappers provide exception handling. Program execution is returned to the location of API_END and the "result" object should be checked. Seems straight forward. However, in practice, I don't understand how the addition of these wrappers could prevent an error in the first place. For example, I had some code without the wrappers that would occationally crash. We identified steps that would reliably reproduce the crash. The problem was creating a 'new' attribute on a face. Since this could be considered modeling (as we're changing or adding to the face object), I added the wrapper macros. I expected the program to jump to API_END and find that result was not "ok". To my surprise, the program run fine, does not jump to API_END and result is "ok".
There's more to API_BEGIN and API_END than meets the eye. Does API_SYS_BEGIN_INTERNAL (behind API_BEGIN) provide internal error handling that actually causes problems when it's not set up properly?
I also have a question about how tightly it should be coupled with api routines. If I have a set of simple statements, they should be wrapped by the macros. If I have the same set of statements in a loop construct, should the wrappers be inside the loop or is it sufficient (and more efficient?) to place the macros around the outside of the loop?
09-11-2007 01:18 AM - edited 09-12-2007 10:03 PM
Message Edited by sbrooks57 on 09-13-2007 12:03 AM
09-12-2007 09:08 AM
09-13-2007 10:17 AM
The macros also enable ACIS exception control, which allows us to identify and catch hard errors such as floating point exceptions and segmentation violations, as well as internal ACIS errors. We enable this behavior in the outermost API_BEGIN and restore the original settings in the outermost API_END. Both error control and change tracking help provide a robust transaction system that maintains the integrity of models during modeling operations. The entity changes logged in bulletins on the history stream are used to roll back a model after a failed operation, to provide undo/redo capabilities, and can be inspected to determine what changes occurred during an operation. These abilities come at the expense of memory. However, applications that do not require complete history for undo/redo purposes can automatically limit the amount of logging information retained to that of the current operation by disabling API logging with the api_logging function.