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.
Comments are closed.
13 CommentsOldest to Newest
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?
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.
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.
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.
That’s an interesting thought.
Of course in a perfect world the debugger would recognize the difference between the case you describe (I write bad code which causes an error further down the stack) and the case I was thinking of (I run cd(‘asdf’) from the command line at some point during my day.) It seems like there are two reasonable options:
(1) Don’t stop unless the error is explicitly in the file requested. This is what I was thinking of when I wrote my original comment. Of course this leads to the situation you described. Still not a bad option to have.
(2) Don’t stop unless the file requested is somewhere in the stack when the error occurs. This would kick over to the debugger whenever a problem could conceivably be found in the file I was working on, but would not force a stop when I have a fat-finger mistake somewhere else. I like this better than #1.
So to flush this out a little bit, my request would now be:
A – add the following forms to DBSTOP
(11a) DBSTOP in MFILE if error
(12a) DBSTOP in MFILE if caught error
(13a) DBSTOP in MFILE if warning
(14a) DBSTOP in MFILE if naninf or DBSTOP if infnan
(15a) DBSTOP in MFILE if error IDENTIFIER
(16a) DBSTOP in MFILE if caught error IDENTIFIER
(17a) DBSTOP in MFILE if warning IDENTIFIER
B – These forms would stop execution if
B-i The currently defined criteria for stopping was met
B-ii The MFILE specified was present in the DBSTACK
This would stop execution whenever the MFILE either had an error, or exposed an error in some other code. But it would not stop execution when I was doing work from the command line, or exercising some unrelated function.
I have archived this discussion in the enhancement tracking database for the Development team to monitor.
I think the development team might have a look at “proper” IDEs, such as Visual Studio. When there is no debugging information available, the debugger breaks at the point in the stack where there is still information. The stack is fully there, but the use is not immediately pointed at the disassembly (unless specified in an option).
In Matlab, this could be implemented via an additional path-like specification. The user can specify paths where the debugger should not break in a function within that path, but in the file calling this function. This would save the user to manually navigate up the stack to the relevant function. If the error is buried somewhere inside, then the user still has the option to “dbdown” to the location of interest.
GUI wise, there would be nice ways to implement this.
The user could simply “ignore” files or their paths in the editor once Matlab ends up in the “wrong” function.
Lastly, may I suggest the possibility to specify an “entry-function” for the editor? May be I miss it but when working with several files it is truly annoying to continuously switch back an forth between open files just to start the “project”, fix the error, go back, start the project, fix the error…
Came here on a Google search… what I want (and am submitting an enhancement request for) is a “dbstop now” or “dbstop here”. The at line number stuff can be useful, but for quick and dirty stuff I want to do:
dbstop now if ~isequal(input, expected_input);
I take it that you already know about conditional breakpoints that can be added by clicking on the breakpoint in the editor?
Thanks for the idea,
Yes, I am aware of conditionals, but if you “clear all” they go away with your variables, and same with quitting your session. The solution I came up with uses the “keyboard” command that I wasn’t aware of that support told me about (it’s in “doc dbstop” but not “help dbstop”).
Anyway, here’s what I do now:
% In init section at top
if debug && ~isequal(input, expected_input), keyboard; end;
That drops me into the debugger the same way (with F5 continuing the code). However, if I am sick of it, I can just type “debug=0” and then F5/dbcont will let it continue past it.
did you get any comments from the development team regarding the “dbstop in mfile” suggestion by Morrison? I think in particular it would make sense to break in the stack frame of on of the mfile indicated. If the error is not in the developer’s code but somewhere hidden by the intricacies of one of the internal/supplied/toolbox function, then this leaves the option to dbdown to the bottom of the stack. On average, this would save a lot of stack frame leveling.
There could be a small button in the editor saying “dbstop in all open mfiles”, and “dbstop at error”.
Oh yes, a mfile to specify when pressing f5 (so that you don’t have to switch back and forth between windows for debugging) would be nice, too.
We make it a policy not to comment about upcoming features, but I can say this suggestion was of interest. Sorry for not being able to say anything more.
I just wish MatLab allowed use of dbcont when there is a dbstop as a result of an error. FreeMat has this, and its great! (actually in FreeMat its called “return”, not “dbcont”)
I don’t want to put a try catch block around every function that might have a problem that could cause me to restart a long running program.