07-29-2016 04:12 PM
It is not the first time when I see api_... functions crash internally, but this time I was surprised to see that the check function itself (api_check_entity) crashes while performing a check!
I usually add API_NOP_BEGIN/END to avoid application crash in cases like this (anyway, I believe it is a good practice when one calls a query function which should not change the model).
Is it enough to add API_NOP_BEGIN/END to deal with consequences of api-crashes, or maybe something else has to be done?
Solved! Go to Solution.
07-29-2016 04:24 PM
Even the API_NOP_BEGIN, END isn't really needed. If you call an ACIS API, it has API_BEGIN/API_END in it. It will catch access violations, FPEs, and other errors. The status is reported using the outcome object. All you need to do to avoid an application crash is
(1) don't resignal the error in the outcome object (check_outcome) or
(2) use a try/catch block where you want the error to stop propagating.
It is important to be careful when the API macros are nested.
// then do other stuff
is bad code because only the top level API has a bulletin board for it (except for NOP and TRIAL blocks). When you ignore the status in an outcome, it can leave the model in a bad state. I would recommend either
// other stuff
// other stuff
instead. (I always use the later, becaue if you rely on explict if/else to keep track of status the code can get kind of cluttered just monitoring status. exceptions do this for you.)
Also: NOP blocks may erase cached data that is computed in the course of an API (e.g., bounding boxes, par boxes, ps polygons,). recomputing this can take some extra time. The NOP block does stop you from changing the model though. Query APIs may do caching but they shouldn't change "observable" behavior.
Provided you are managing exceptions correctly, you can use NOP blocks for queries if you want to be slower but careful, or no NOP blocks, if you want to be fast but possibly get slight state changes in the model.