Doug's MATLAB Video Tutorials

April 28th, 2008

MATLAB Basics: Using dbstop if error

When MATLAB throws an error, if you are in a function, you will end up at the base workspace and lose access to the variables as they were in the function when the error was thrown. This makes it difficult to understand why the error occurred. With the debugger, MATLAB can stop when the error is thrown, so the variables are still in scope. This makes debugging much easier.

By Doug Hull

09:48 UTC | Posted in Format: PodCast, Format: Video, Level: Basic | Permalink | 4 Comments »

You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

4 Responses to “MATLAB Basics: Using dbstop if error”

Eric S replied on August 28th, 2008 at 11:37 UTC :

It would be great to stop the debugger from coughing somewhere inside the more “internal” functions.
Is there a way to specify not to barf in certain directories, or in the ones you’re developing in only?

Cheers,

Eric
Scott Hirsch replied on August 28th, 2008 at 12:42 UTC :

Eric -

That’s a nice suggestion. I often get frustrated when debugging GUIDE guis and ending up inside of guimainfcn. I can’t think of a direct way to handle this – there might be some games you could do with stopping based on certain error IDs, but I’m not sure how far this would get you.

- scott
Morrison Lucas replied on October 28th, 2008 at 12:56 UTC :

Hear hear!

I generally have one set of files that I’m debugging, and desire the “dbstop if error” functionality for files in that set. Everything else I don’t want to hear about, just give me the error message and let’s move on.

In terms of the interface, one possibility would be to implement the following calling convention:
DBSTOP in MFILE if error
As well as the “caught error”, “warning” variants.

-Mory
Doug replied on October 29th, 2008 at 14:57 UTC :

Mory,

I understand what you are looking for in an abstract way, but I am having some problems with understanding particulars.

If I am writing code, the bad code might be in *my* code, but might not manifest until a deep call, ie

sum(‘a’, 1) %let’s pretend this code caused an error in SUM

Would you want to stop? The ‘error’ is thrown by SUM which is not in your directory, so should it be skipped or not? I personally want it to stop and then just run up the stack until I get to *my* code.

Like I said, I think there is something to this suggestion, but I am not sure what would cause a DBSTOP and what would not.

-Doug