Home
Reply
Regular Contributor
Posts: 58
0
Accepted Solution

Handle api_... crash?

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?

 

Thanks you!

 

Highlighted
Spatial Employee
Posts: 151

Re: Handle api_... crash?

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.  

 

API_NOP_BEGIN

api_facet_entity(ent);

// then do other stuff

API_NOP_END

 

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

 

API_NOP_BEGIN

auto out=api_facet_entity(ent);

if(out.ok())

{

// other stuff

}

API_NOP_END

 

or

 

API_NOP_BEGIN

check_outcome(api_facet_entity(ent));

 

// other stuff

API_END

 

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.

 

Eric