Shortcircuiting multiple dbquit commands

Many times I find myself in a workspace, making an error, which throws me into debug mode, repeatedly making mistakes while trying to figure out what's going on, and then having to type dbquit, many many times to get myself back to a particular workspace. Is there some way to shortcircuit this process and get back to space I want to be in with a single command? (perhaps for example an undocumented argument to `dbquit` like dbquit('dumb')?) Here's a a really silly example. Suppose the following lines are in a file called dumb.m.

dbstop if error
1
f = @(x) x + y
f(1)

If you run the file dumb, then you'll see the following error:

Undefined function or variable 'y'.
Error in dumb>@(x)x+y
Error in dumb (line 4)
f(1);

and dbstack will return

In dumb>@(x)x+y
  In dumb (line 4)

Now, if you do a really stupid thing and type `y` three times, and then decide you want to get back to the workspace `dumb`, you'll need to type `dbquit` several (in fact 4) times, and, to be safe, `dbstack` after each one, to make sure that you haven't gone too far and exited the workspace `dumb`

The obvious answer---don't keep making the same stupid mistake---isn't applicable, since in my actual instances, the mistakes aren't so stupid. Thanks very much for any suggestions.

[Prasad Mendu]

One of the possible workaround could be using "dbclear if error" instead of "dbquit if error". Will this fit your use-case?

[Walter Roberson]

The situation is messier than that.

The flow for me is like this:

I "dbstop if error". I run. I get an error. I start exploring the reasons and start exploring what I need to do to solve the problem. If I make a mistake at the command line, I do not want the "dbstop if error" to create a new stackframe or new debugger context. But if I call a function from the command line, and that generates an error, then I probably do want that to be caught. That has to create a new stack frame, but it would be preferable to not create a new debugger context.

Currently if you make an error at the command line while debugging when "dbstop if error" is set, then you get a new debugger context generated.

Now, you could advise, "As soon as you stop in the debugger because of a dbstop if error, then execute dbclear if error so that you will not generate new debugger contexts". But if I am testing a function then I might want to catch problems in something I execute at the debugger prompt. But no new context for a typo. So you might advise, "So then just before you execute something you want tracked again, redo the dbstop". Besides this being clumsy, there is still the problem that I do not plan to make typing mistakes while typing in the call that I do want traced, but such mistakes occur anyhow.

So what would be good is if new debugger contexts were not created while you are already in the debugger, so that you do not need to dequit out of them. Still catch problems, create new stacks, just don't create a new debugger context.

I can see, though, that there might then be reason to want to get rid of a new batch of stack frames if you want to go back to where you were before the new error was triggered. That might call for a new command such as "dbpop". The difference between "dbpop" and what dbquit does now is that in this new imagined version, dbquit would always exit the debugger completely and dbpop would not.

[Prasad Mendu]

Thanks for the feedback. I have forwarded this to the respective department so that it may be incorporated in the future.

[Leo Simon]

Walter's suggestion about a new command would achieve exactly what I wanted! Or, for backward compatibility, couldn't dbquit be modified to accept an argument, e.g., dbquit all, which would exit the debugger completely?

[Walter Roberson]

dbquit all does exist these days ?

[Leo Simon]

Unfortunately dbquit turns out to be too aggressive for my needs, what I need is what you suggested originally, @WalterRoberson, i.e., a command that would take me back just to the workspace where I made the last error. I don't want to quit out of the entire program. I realize this is a harder ask, but it would be tremendously useful.

[Walter Roberson]

I encountered difficult situation the other day. I was debugging with "dbstop if naninf" inside the ode45 code, with some animatedline() addpoints() inside my objective function, and when drawnow() was hit, something inside the graphics handling system would breakpoint. I would dbcont and it would go right back to breakpoint again, over and over again, I would have to continue numerous tens of time in a row to make any progress. dbquit wasn't enough to solve the issue.

Ah... I just realized that I initialized the animatedline() with nan, nan, so it might have been firing while it was copying those points while adding more points....