Question

BUG: I used cell-arrays in the underlying functions, bad!

I cannot understand why restarting Matlab result sometimes into more verbose error messages that help me to actually solve problems. Now I am trying to find a command that makes Matlab showing as much information as possible. For example the below index-exceed-dimension error is totally useless with my recursive algorithm -- this is the specific algorithm where Matlab have once revealed the specific line but now for some reason only telling the vacuously the name of the algorithm

Index exceeds matrix dimensions.

Error in Dij (line 65)
        Dij_=Dij(ii,jj,[II,k],[r,q_(k)]);

where you can see that I am running the algorithm Dij failing on the line running the algorithm Dij again.

How can I get more information about the error? Or how can I get inside any point in the recursive algorithm? -Linebreak and trying to get inside that point just fires the error.

Was it helpful?

Solution 3

It is not evident in the description where the bug is because it does not show with which tools I programmed the underlying functions: I used cellarrays and for some reason Matlab returns far worse error messages with cellarrays than with Matrices so:

my genuine recommendation is avoid cellarrays and use matrices -- and if you need to play with a lot of zero cases, use the ready sparse functionalities because they have far better debugging verbosity!

Instead of wasting too much time to debugging, choose the right tools and Matlab is excellent with Matrices and you can see it in the quality of error messages.

OTHER TIPS

Add a try catch block on your recursive algorithm, print the information you think it would be valid and then rethrow an error that will terminate your other callbacks silently.

You may use the keyboard matlab function to check the matlab workspace as the recursive function goes on. You can choose to add it just before your error message, so it will be called every time it goes deeper in the recursive level, so that you can check what is going on, or you can add it when the error occurs (on the catch).

This is just a draft, it may contain errors, adapt it into your needs:

try
  % recursive routine
catch ext
  if strcmp(ext.identifier,'MyPackage:MyRecursiveRoutine:TerminateSilently'))
    % Do nothing
  else
    % Display useful information, you edit it to add information you think would be valid, i.e.:
    disp(ext.getReport)
    disp(yourVariable)
    % get dbstack size, to see how many recursive functions, i.e:
    theStack = dbstack;
    recursiveCalls=sum(strcmp({theStack.name},'MyRecursiveFcnName'))
    % You may even add the keyboard function here, so that you can inspect your workspace:
    keyboard
    throw(MExcept('MyPackage:MyRecursiveRoutine:TerminateSilently',''));
  end
end

Run dbstop if error before running your code to drop to the debugger exactly at the point of error. From there you can inspect the variables, including whatever variable you've carried along to ID the level. You can also run dbstack to see the full call stack.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top