Keeping the debugger out of the bowels of the machine...dbstop error question

I am trying to make progress in testing code, but I encounter an error. No problem, just enable dbstop on error and run again. The error occurs about three layers down in the "ismissing" function. Boom, boom, boom! Three functions open up, and I am down in the "bowels of the machine." I don't understand that code, I can't touch that code, and it does me little good being down at that level of code. Why am I here? I have asked the function to operate on a cell array in a way that it cannot understand. I know that from the error statement. I don't need to be down in the middle of a private function. Even worse, now I am several workspaces below where I am actually working. So, I have to close all the functions, and the dbup several times back up the chain to where I am working, and where I want to remain.

Does anyone know of a way to restrict the debugger to remain in the current workspace, and not descend into Matlab's "private" function calls?

[Joel]

By the way, I've actually put up with this annoyance for well over a couple decades, but it seems to occur, or at least bother me more now than ever!

Answer 1

[Jan]

This can be avoided by an exhaustive error checking, which catchs all not matching inputs as early as possible. Massive TRY-CATCH blocks helps also to handle problems in higher levels.

Both methods have the drawback of impeding the performance. E.g. in polyfit the error cheking took more than 50% of the processing time - I've tested this in old versions only.

A programmer have to decide, if the performance is optimized for correct standard calls or for the debugging. Both strategies have their advantages.

You could write a script, which calls dbup until the wanted level is reached. I'd avoid all further automatic confucions during debugging and I'm happy to stop in deeply nested code, when it is so easy and fast to use to dropdown menu to reach the higher functions.

Answer 2

[Image Analyst]

Don't tell it to stop on error. Then the error will bubble up to the line of code you're stepping on, not deeper down. It will either be handled by your catch block, if you have one, or throw up a bunch of red text in the command window, but you'll remain in your code, not deeper down. Your code should stop at the line where the error was thrown or go to your catch block. So you know where to put breakpoints -- either on that line of code and/or in your catch block.

If you do end up deeper down, you can click the "Step out" to finish executing that function and step out to the calling routine and stop there. Continue stepping out until you end up back at your code. But again, you don't need to end up deep down if you don't say dbstop on error.

[Joel]

Well, if the error occurs prior to reaching a breakpoint, then the debugger will not be entered at all. When the error is encountered, the error message is produced, but I have to rerun the script/function with "dbstop error" in order to debug the issue farther. Many errors do not result in leaving the current workspace. Some, however, such as the "ismissing" function, consider the calling parameters valid and descend far down into several function calls before encountering an error. Since the error is in the center of some low-level function, I cannot continue execution, nor can I step out. But I cannot reach the point to ascertain what the problem is in the first place without the "dbstop on error."

I think that this may be reportable, since I believe MATLAB strives to perform all error checking prior to letting incorrectly formed parameters past the "front gate." This is becoming challenging with all the ways we can now form, store, and process complicated data such as structures of cell string arrays (as I have, using "xlsread").

[Image Analyst]

When the red text gets spewed into the command window. See what is the lowest line in the call stack that has your code in it. Then set a breakpoint on that line and run it again. It will stop there instead of deep inside some built-in function. Now, before you execute the line you can investigate your variables and see which of them might be causing the problem.. Then type F10 to step on that line and you should see the error in the command window and your program will either abort then (after which you'll lose all your variables unless you're running a script rather than a function), OR it will branch to the catch block (if you have one). This is the way I do it and virtually never end up deep within the bowels of MATLAB (unless I clicked the "Pause ||" button on the tool ribbon or repeatedly hit control-C.