@Bob – you are mistaken: s=warning(...) returns the warnings state as it was before the state was modified, so my code is correct. There is no need for a separate call to s=warning;.
I agree that this is not clearly explained in the official doc-page, but you can see the behavior in the example that is provided in that doc-page: https://www.mathworks.com/help/matlab/ref/warning.html#buh8kqc-13

I have one question, though.

At the very start of your example, you have:

% Set a couple of warnings to temporarily issue errors (exceptions)
s = warning('error', 'MATLAB:DELETE:Permission');


and then at the end, you have:

% Restore the warnings back to their previous (non-error) state
warning(s);


Won’t this restore the warnings back to the state with the first warning-converted-to-error, not the “previous (non-error) state”?

To restore the warnings to the previous (non-error) state, shouldn’t your example be:
(Note that the assignment of s has changed.)

s = warning;
warning('error', 'MATLAB:DELETE:Permission');
...
% Restore the warnings back to their previous (non-error) state
warning(s);


That seems to be the the way my MATLAB version (R2018a) works.

Or am I misunderstanding something?

@Ken – I cannot reproduce your report, it works as expected for me even on R2022b

try
    a = [0,0;0,0]\[1;1];
catch
    disp('Caught.')
end
lastwarn('')
warning('error','MATLAB:singularMatrix')
try
    a = [0,0;0,0]\[1;1];
catch
    disp('Caught.')
end
lasterr
lastwarn

@Noam – I am not aware of any way to achieve this. But I very rarely say that anything is impossible…

@Steve – thanks for the clarification, duly noted.

Try/Catch by its very nature does a *lot* of housekeeping under the covers, to build stack frames that can be unwound back up to higher levels, which the if/else construct does not have to do. If a condition is a simple test (e.g. >0 or isempty) and in a very tight loop, it can be much more efficient to just use the if/else construct.

After the above experience I now reserve try/catch for main-level to second-tier level functions and try to keep them out of the often called modules. Try/catch is great, but use them wisely. If its called more than 100 times in a given run then if/else may be a better bet. For checking user input or possibly tainted network data, try/catch is great! Using it in a loop running a million times, maybe not so much.

Thanks, the reason I am doing the coding this way is that rdivide is generating these error messages when it enounters a singular/badly conditioned matrix, so rdivide is clearly already using rcond() to test the conditioning of the matrices. I need to check the conditioning of the matrices, rather than me having to call rcond() again to duplicate this work, I would just like to get access to the rcond values and/or the decision as to whether the matrix is badly conditioned or not that rdivide is already producing. Ideally within a parallel structure if this is possible?

To be clear the parallel toolbox does still produce these warning messages, its just when I add:

warnState(1) = warning('error', 'MATLAB:singularMatrix'); 
warnState(2) = warning('error', 'MATLAB:illConditionedMatrix'); 

to turn them into errors that the divergence between parfor and for arises.

Would I be better to just call rcond() myself, this will mean duplication of work (which is annoying), but as least it will work.