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.

-Doug

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.

…dreaming,

Eric

Anyway, here’s what I do now:
% In init section at top
debug=1;

% Later…
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.

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,
Doug

dbstop now if ~isequal(input, expected_input);

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…

Cheers,

Eric

Thanks,
Doug

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
AND
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 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

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