Disable automatic termination of mex functions

There are a bunch of mx and mex functions that will halt execution of a mex file if something goes wrong (I assume by using longjmp under the hood).

For the function I'm writing, if the mex function terminates without giving me a chance to clean up, it would be Bad. Therefore, I have to avoid calling functions that can terminate unless I clean up first. This is simple enough for functions like mexErrMsgIdAndTxt, but there are a whole bunch of functions like mxCreateString that can terminate as well. If I'm building a complicated return value, having to release and reacquire my library state every time I make a potentially terminating call is not fun, not to mention slow.

Is there a way to disable automatic termination (so that functions will just return an error code, like they would in a standalone exe), or at least a way to be notified if the mex function terminates?

Answer 1

[James Tursa]

Not from within the mex function that I am aware of. When these errors occur in an API library routine, of course the routine doesn't return back to the mex function so there is nothing to catch there. Other that using a try-catch with the caller, I don't know what else you can do directly. For the memory allocation stuff, I suppose you could put in code to see how much contiguous memory is available before calling a mxCreateEtc function, but that would be kind of a pain.

One approach is you could hold your critical variables at the top level of your code so they stay intact when the error occurs, and have top level flags set before & after every API call to keep track of successful progress. Then in your caller catch block you could call back into the mex routine, which would immediately detect that an API function didn't return from a previous call (via your top level flags), and you could then do your clean up.

You can of course register a mexAtExit( ) function for when the mex routine gets cleared from memory, but there isn't anything to catch the runtime errors (memory allocation etc) from within the mex routine itself.

[Carl Banks]

That actually isn't a bad workaround. The actual mex function is low-level and not usually called directly by the user; and it's not a big deal to add a try...catch to the M-script.