Loren on the Art of MATLAB

Turn ideas into MATLAB


Loren on the Art of MATLAB has been archived and will not be updated.

Useful Debugging Commands and Tips

In my personal history using computers, I have learned to embrace debuggers to help me understand what's going on in my code.  


Short List of Lesser Known Debugging Commands

Here's my short list of some useful debugging commands that might be less well known, especially for those of you who primarily use the interactive debugger as part of the MATLAB editor:
  • dbstop if error
  • dbstop if caught error
  • dbstop if warning
  • variants with specific message ID
  • dbstop if naninf

An Example

Let's set up an example so you can see what's going on. I first make sure my debugger state is all cleared up and then create a struct which I will then test to see if a particular field exists.
dbclear all
s.fred = 1;
dbtype isfieldTryE
1     function tf = isfieldTryE(s,f)
2     %ISFIELD True if field is in structure array.
3     %   F = ISFIELDTRYE(S,'field') returns true 
4     %   if 'field' is the name of a field
5     %   in the structure array S.
6     %
9     tf = true;
10    try  
11      tmp = s.(f);
12    catch E
13        % I don't care why it failed.
14      tf = false;
15    end

First Experiment

What happens if I ask to see if a particular field exists, and ask for MATLAB to stop if there's an error?
dbstop if error
ans =
ans =
What you can see is that testing for either an existing or non-existent field sails on through. And I get the same behavior if I try to stop only for an appropriate message identifier.
dbstop if error MATLAB:nonExistentField
ans =
ans =

Stopping for a Caught Error

To stop for an error that is caught, I use the following form of dbstop (in this case with the message identifier).
dbstop if caught error MATLAB:nonExistentField
ans =

Caught-error breakpoint was hit in isfieldTryE at line 11. The error was:

Reference to non-existent field 'freddy'.

ans =
Now when I ask for a non-existent field, the debugger stops in the catch block. And to resume, I use

Common Issues

There are a few common issues that puzzle people when debugging. They include:
  • breakpoints disappearing when debugging. This is often caused by a clear all in code being run. See, for example, this post.
  • name collisions. These are caused either by using a variable name the same as a name for a MATLAB function, or having multiple functions with the same name. Using which can help you figure out what's going on if you realize there's a nameclash.
  • variables not being present. This is often an issue of not understanding scoping in MATLAB, including inputs and outputs of functions, what workspace graphics callbacks execute in, scripts versus functions.

Handy Tip

Here's a useful tip I use, for debugging, or sometimes to just find out the signature of a function. Using dbtype 1 fileName and you will see the first line of the file displayed. If you write your code as we tend to do at The MathWorks, the first line of a file containing functions will be the function definition line. Voila, you have the signature!

Other Debugging Gotchas and Tips?

You might find some additional debugging tips on Doug's blog. Some people like the keyboard command or omitting terminating semicolons but I prefer to debug without editing my code, when possible. Do you have other tips to share that you find helpful? Post them here.

Published with MATLAB® 7.5

  • print


To leave a comment, please click here to sign in to your MathWorks Account or create a new one.