Hello,
Very informative post. I found a bug in the code in the ‘Trapping warnings block’: you initialize your counter with filesIndex = 1, but index with filesList{fileIndex}. There is a mismatch between filesIndex and fileIndex (i.e. one is plural and the other is singular).

Best,
John

@John – thanks, corrected

Hi there, I have tried to use your template above to do my own error trapping. However, I have found some rather strange behavior. When I run the code as shown below, the code runs and delivers the correct results. However when I %matlabpool open, %matlabpool close and change parfor to a simple for, the code will not run and I get the following error:

Running...       ??? Error using ==> mldivide
Matrix is singular to working precision.

Error in ==> NSS_betas at 11
    betas = G\data.y2.';

Error in ==> DElambda at 19
        betas(:,ii) = NSS_betas(P1(:,ii),data); end

Error in ==> Individual_Lambdas at 46
    beta{ii} = DElambda(de,dataList, @OF_NSS);

Now I am not surprised to be getting the error, this is the result of the

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

I included (there is not try catch yet included yet in the function DElambda). What confuses me though it why when I run this code as part of a parallel loop no errors are generated? Do trapping warnings work with parfor?

clear all, clc
load Euro_CRM_22_12.mat
matlabpool open

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

mats  = 1:50;
mats2 = [2 5 10 30];

% RO: unloop these
de = struct(...
    'min', [0;0],...
    'max', [50;50],...
    'd'  , 2,...
    'nP' , 500,...
    'nG' , 600,...
    'ww' , 0.1,...
    'F'  , 0.5,...
    'CR' , 0.99,...
    'R'  , 0,...
    'oneElementfromPm',1);

% RO: initialize beta
beta  = cell(size(rates,1),1);

clc, fprintf('Running...       ');

%for ii = 1:size(rates,1)
parfor ii = 1:size(rates,1)    
    % RO: use status indicator for things that take this long
    %fprintf('\b\b\b\b\b\b\b%6.2f%%', ii/size(rates,1)*100);
        
    dataList = struct(...
        'yM'   , rates(ii,:),...
        'mats' , mats,...
        'model', @NSS,...
        'mats2', mats2,...
        'y2'   , rates(ii,mats2));
    
    beta{ii} = DElambda(de,dataList, @OF_NSS);
end
toc
matlabpool close

@Baz – apparently this only works in a non-distributed environment…

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.

Just a note. The Try/Catch construct can have a tremendous performance hit if used inside a loop that is executed many many times, but this can very by environment. I have one report that would run fine on my laptop in a matter of hours, but when placed on the Big-Server in the basement that time literally turned into days. Profiling on each machine showed a very clear difference in the time allocated to the same try/catch, running on the same dataset, in the two different environments. After removing the try/catch statement from a very tight loop in the core of the main algorithm, that change made all the difference.

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.

@Steve – thanks for the clarification, duly noted.

[…] additional input (a message identifier). It is used for trapping/catching warnings as errors. See this Undocumented Matlab post and this MathWorks Newsgroup […]

Hi Yair,
Do you have any idea how could I find all the warnings occurred since a certain point and on?
lastwarn returns only the last warning, but let’s say that I want to test some code, and I want to track ALL the warnings it had produced.
Do you think it’s possible?

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

Why does the second catch block in this code example not work? (It works if you restart MATLAB and then omit the first try-catch block.)

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

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