How do I do this without using try/catch?

I am using waitbar within Run_pushbutton_Callback (GUIDE GUI):

function Run_pushbutton_Callback(hObject, ~, handles)
try
wb = waitbar(0,'Computing...','Name','MyProgName');
 wbch = allchild(wb);
 jp = wbch(1).JavaPeer;
 jp.setIndeterminate(1);
 
 % call main function        
handles.mainfunc(S); % S is structure of variables

 close(wb); % close dialog box 
catch ME
 close(wb); % close dialog box 
 errorMessage=sprintf('Error in function %s() at line %d.\n\nError Message:\n%s', ...
        ME.stack(1).name, ME.stack(1).line, ME.message); 
fprintf(2, '%s\n', errorMessage);
uiwait(errordlg(errorMessage)); % error dialog
% rethrow(ME); % rethrow the whole error message in command window (if needed)
end 
guidata(hObject, handles);

When mainfunc() throws an error, waitbar still continues blinking - without try/catch. I used try/catch solution to close it. However, Matlab documentation says that the memory optimisation etc is not supported within try/catch: https://www.mathworks.com/help/matlab/matlab_prog/avoid-unnecessary-copies-of-data.html

Also, it looks a bit awkward to use try/catch for entire program.

1. How can I close waitbar after error without using try/catch?
2. How come that in-place or other optimisation does not work within a function and its subfunctions (not nested) if the function is within try/catch block?

Answer 1

[Walter Roberson]

To get rid of the try/catch for closing the waitbar, use

cleanMe = onCleanup(@() delete(wb));

If you put that within a function, you do not even need to remove the waitbar yourself when the iteration finishes -- the waitbar will be removed when the function returns normally. The waitbar will also be removed when the function is terminated because of error() and so the variables are being deleted.

(You can still delete the waitbar early if you want to, such as if you want to start a different waitbar.)

The reason that some optimizations are disabled within try/catch:

When you have a function without try/catch, then the implicit "contract" with the Execution Engine is that the Execution Engine will do the operations implied by the code and have the answer ready by the time the function returns.

Notice I did not say that the contract is that it will execute the lines in sequence: MATLAB is permitted to rewrite operations according to what the operations are supposed to "mean" instead of what the code lines say in detail.

For example if you have a loop that is doing

for K = 1 : 1E8
   D(K) = A(K) + B(K) .* C(K);
end

then there is no "contract" that MATLAB will execute a loop 1E8 times and do one addition and one multiplication for each loop iteration: MATLAB is permitted to instead call into a high performance linear algebra "multiply and add" that can split up the iterations between cores and which might even use a hardware FMA (Fused Multiply and Add -- https://en.wikipedia.org/wiki/Multiply%E2%80%93accumulate_operation ) . Or which might not for sutble precision reasons, but the high performance code might know how to stick the ADD in the Branch Delay Slot and so more or less "get it for free" .

There are cases where MATLAB is able to recognize that a particular operation something like W * X * W' implies some properties of the resulting matrix and because of that is able to take more efficient calculation pathways on some other operations on the same line. Likewise in theory if MATLAB recognized that a particular operation should return a symmetric result, then MATLAB is permitted to only actually do one triangle of it and fill in the second half from the results of the first half.

That said:

There is a "contract" with the programmer that at the time an Catch exception is taken, that variables will be in a state as if the lines had been performed as written until the place of the exception. And MATLAB finds that the easiest way to achive that sometimes is to disable some of the optimizations within a try/catch.

In theory the restriction should only apply to code that appears directly inside the try block, along with telling any called routines that do in-place overwriting that they are not permitted to do that for the variables that are in scope at the time of the try. Nested functions can share variables so they might have to be throttled. But called functions that do not do in-place optimization do not have to be throttled, because they have their own contracts and their internal variables that might be out-of-phase cannot get returned back to the caller in the case of an exception in the called routine.

[G A]

Thanks, Walter! Do I get the idea of the last paragraph of your answer: if say, Main_prog consists of couple of lines of its own code and hundreds of functions to be called with some dependency from each other, then try/chatch affects optimisation of those two lines only, i.e, there is no problem if the called functions do in-place optimisation not itself but within their called (not nested) subfunctions?

[Walter Roberson]

In-place optimization cannot, in this situation, always be done on variables that are passed as parameters

try
   foo = outer(foo);
catch ME
   stuff
end

    function A = outer(A)
      A = B(A);
   end
   function A = B(A)
      A = in_place_operation(A);
   end

In the absense of the try/catch, in theory the information about in-place eligibility could be passed into outer, and outer could detect that the eligibility continues and pass that into B, which in theory could detect that eligibility continues and pass it into in_place_operation. But, if an exception occurs and climbs the chain to the catch, then the in-place modification is not permitted to have made it into foo -- the assignment of the results of the call to outer() is considered not to have been made until outer() "completes" normally.

But... if outer had been

   function A = outer(A)
      A1 = A;
      A = B(A1);
   end

the B and in_place_operation would be permited to operate in-place even inside the try/catch since their in-place operation would be against A1 which is copy-on-write and not A itself. The return of B(A1) into A is not an in-place operation for A .

To summarize:

Some operations cannot be optimized (at least not the same way) when directly in a try/catch.

Some in-place optimizations have to be disabled on a variable-by-variable level no matter what the call depth is inside a try/catch block.

But any variable inside a function that is not being shared ("shared variable", or chain of directly passed parameter) with a variable in the try/catch context, can be optimized inside of functions.

[G A]

Thanks!