How to get Matlab stop on my file upon error?

Hi,

in old Matlab version I could use "stop on error" under "Run" commend. Execution would stop prior to executing a command that will result in error. Very usefull feature when trying to debug your code.

Currently I'm using MATLAB 2021b, and if error occurs it open usually an extra one/two MATLAB inner files (see snapshot attached).

Is there away to configure it somehow to work as in older versions? I want matlab to halt before the error, to have all the variables in the WS, etc..

[Bjorn Gustavsson]

Most of the time the debug-setting:

>> dbstop if error

still works. It stops after the error has occurred though, so if it happens deep down in a function-call-sequence it might take you a number of dbup-calls to get where the problem has its roots.

Does this never work for your current version?

[Mark Golberg]

I will try to explain.

Let's assume I have a simple function:

function m = my_func

a = rand(10 , 1);

m = a(11 , 1);

end

if "Pause on Error" is ON, when I call for this function it will stop on the second raw (m = a(11,1)), right?

It make sense, and that's the behaviour I'm expecting.

BUT,

when I have error in my AppDesigner GUI, each error open an addition some deeper level MATLAB function, which I have no interest of.

For example, I'm using MATLAB function "find". and there is an error in how I call it, or something like that... I'd like MATLAB to halt on the line where I actually use the "find" function, and not go to some deeper matlab implementation of the "find" function.

It was like that with older MATLAB version.. prettry sure that in 2018 it was still ok, but in 2020 and higher, I get this weird and very inconvinient behaviour.

[Bjorn Gustavsson]

So you want the a setting for the debugging that puts you in the workspace of "the deepest of your functions" in the call-stack when the error occurs, or one step deeper? That might be an interesting feature. I've only ever accepted getting the debug-prompt at the line where the error occurs, which might be un-interestingly deep, but it will make it explicitly clear where the error is (since it might not be obvious at the point an internal matlab-function is called), and I'm ever only a few "dbup" calls away from my entry-point.

[Bruno Luong]

Really? AFAIK Matlab always stop at the inner most mfile, even for "old" MATLAB.

One workaround is to put

try
    call_stockfunction
catch
    keyboard
end

in *your* code, then you can call manually call_stockfunction at the prompt or do something else to find out the issue.

[Bjorn Gustavsson]

@Bruno Luong: maybe there are a few more levels of function-calls inside the internal m-functions so that one ends a few steps deeper in the function-call stack now than earlier? This is something I've "felt on a perhaps-basis".

[Bruno Luong]

Possibly, but then it's not the behavior of dbstop if error but due to change of MATLAB stock function hierarchy, or the way OP's code is called within or not an App from R2021b.

Just to make sure that OP doesn't imply the wrong source of the "problem".

[Mark Golberg]

@Bruno Luong @Bjorn Gustavsson

Not sure I understand the discussion here.

I'm asking for a very basic functionionaly, that up untill recently was very trivial in MATLAB.

I run a code... I have functions calling to functions, calling to functions...

Loops, ifs, etc...

So, if I have error somewhere "down the flow" of the code, and I choose "Pause on Error", I simply would like MATLAB to STOP exactly at the LINE of the error, in MY function. Obviously, the work space would be the one relevant to that "forzen" fragmenet in time, where the error occured.

I do NOT want to see any deeper layer MATLAB internal function, such as the ones I've posted in my original questions.

I do NOT want to use "try" & "catch", as error will happen every time in different places.

Even in my current version of MATLAB 2021b, it happens when I use "regualr" scripting and function (without any gui...).

BUT, when I work with AppDesigner, I have this strange phenomena, which makes it quite annoying & inconveinent to debug the error.

Is there any setting/confiction that could ammend this?

[Matt J]

If you can, I would atttach a simple .mlapp file that reproduces the issue.

Otherwise, I agree with Bruno. I've noticed no big change in the way the standard debugger behaves since Matlab 2018, so it must be something specific either to the user-supplied app code, or to appdesigner itself.

[Mark Golberg]

attached 2 simple files to demonstrate the issue.

*.mlapp with a pushbutton, that calls for moose.m function.

In moose.m there is an error in the code.

I've chosen to "Pause on Error", but instead of stopping in my moose.m function, MATLAB open 2 internal functions:

"AppManagementService.m" & "AppBase.m", and stops on some line inside "AppBase.m". Obvisouly the WS correspond to AppBase function, and NOT to my moose.m function, where I'd expect to see WS with my variables, etc..

Does it demonstrate the problem now?

[Bruno Luong]

@Mark Golberg "I do NOT want to see any deeper layer MATLAB internal function, such as the ones I've posted in my original questions."

This happens also with R2018 and maybe all other releases: it stops where the error occurs (within an mfile) so at the depest layer, regardless it is your code or TMW code. There is no such thing as ignoring TMW deep-layer.

Do you work withhAppDesigner in R2018?

[Bruno Luong]

"Does it demonstrate the problem now?"

No it's normal behavior, always was and is like this.

[Mark Golberg]

@Bruno Luong

Yes, my code. What do you mean by "TMW code"?

In 2018 I've worked with GUIDE, and it wasn't like that for sure.

What good is the "Pause on Error" if it's not stops on my line of code but goes to some inner layer and stops on error there?

BTW, why it's happing only with GUI and not with recgular functions/scripts usage?

[Mark Golberg]

@Bruno Luong

"No it's normal behavior, always was ans is like this"

WOW! Seriously? I'm in shock. This is a bizzare behaviour. What's the purpose of it? I want to program to stop on MINE error line of code. I certainly don't care why exactly it fails on some interal MATLAB implementation or whatever.

I want to see MY VARIABLES, to be able to see in this example that function moose.m is trying to allocate value into index beyond the vector lenght.

[Bruno Luong]

"WOW! Seriously?"

Of course I'm serious (but might be wrong despite using MATLAB since 25 years).

[Bruno Luong]

"In 2018 I've worked with GUIDE"

Hah. I though so. GUIDE is not Appdesigner, some deeper layer is not an mfile, apple and orange. You can still use GUIDE with R2021b or R2022a, then you don't see breaking at the deaper layer.

[Mark Golberg]

@Bruno Luong

Please look at the snapshot below.

I call for the same function directly, without any GUI (AppDesigner), and it works perfectly.

Why, if I call for the same function, via a pushButton, suddenly, those weird "AppBase.m" function popup and MATLAB doesn't halt on MY function.

what's different? Is there really no work aroud for this?

[Mark Golberg]

@Bruno Luong

"Hah. I though so. GUIDE is not Appdesigner, some deeper layer is not an mfile, apple and orange."

So Mathwork guys, went from GUIDE to AppDesigner, and ruined this super nice debug functionality... this is what you're saying?

I certainly know what I'm going to speak about in MathWorks Advisory Board , in June this year...

[Bruno Luong]

"Why, if I call for the same function, via a pushButton, suddenly, those weird "AppBase.m" function popup and MATLAB doesn't halt on MY function."

May be because AppDesigner throw an error for some reason and with some purpose, but catch later, and if user does NOT use dbstop if error it does not make a break.

It is just another system than GUI.

"Is there really no work aroud for this?"

No, but you can always make an enhancementt request to TMW. I think it's neat but I doubt they would do it (possibly a lot of works for them).

[Mark Golberg]

@Bruno Luong

thanks. But obviusly I don't want to go back to GUIDE.

I do want for MathWorks, not to ruin (without any good reason) a perfectly reasonable behaviour I had in GUIDE.

And I'll again: isn't it super wierd that if I call for the same function, one time via AppDesigner pushButton callback, and one time directly via command line, I got totatlly 2 different responses?

Am I really the first one who's questioning the logic on what good does it make to show all those deeper layers functions?!

[Bruno Luong]

"So Mathwork guys, went from GUIDE to AppDesigner, and ruined this super nice debug functionality"

I have 0 serious and complex app using App Designer. If that tell you something. Still they progress.

[Mark Golberg]

@Bruno Luong

"enhancementt request to TMW" - how do I do that?

[Bruno Luong]

Enhancement request

[Mark Golberg]

@Bruno Luong

"I have 0 serious and complex app using App Designer" - so, you're still working with GUIDE? Even today?

[Bruno Luong]

Yes still with GUIDE. For two reasons (not yours) : graphical performance wise and I use many features (undocumented) with Java (see Yair blog) and this is no workaround with AppDesigner.

Also the GUIDE that have mfile separated to figure file is a little easier for versioning, this is crucial when many peoples participale in the development.

[Matt J]

@Mark Golberg

What good is the "Pause on Error" if it's not stops on my line of code but goes to some inner layer and stops on error there?

It should be a simple matter for you to step a few layers up in the dbstack menu to your own code.

Though I agree in principle that it would be better if the debugger treated internal appdesigner code as binary code, this shouldn't render "Pause on Error" entirely ineffective to you.

[Mark Golberg]

@Matt J

It should be a simple matter for you to step a few layers up in the dbstack menu to your own code

Can you please explain and/or show how this can be done?

I've tried to do "step out"... it didn't work

[Bruno Luong]

@Mark Golberg From what you described, the error is caused by another thread runing in parallel to your program, your function is NOT on the stack where the error occurs (TBC).

[Mark Golberg]

@Bruno Luong

can you explain more clearly please?

Can you address specifically the simple example I've posted here (with moose.m function)

[Bjorn Gustavsson]

@Mark Golberg: To step up/down in the function call-stack you simply type:

dbup % /dbdown

in the command-window. That way you can move up and down between the function work-spaces as they were at the moment of error. This makes it possible to inspect all variables at every level in the function-call-stack leading to the error. This is vital since it is not necessarily obvious how the function ended up causing an error. Dont rely on pushing buttons.

Also read the help and documentation on debug.

[Mark Golberg]

@Bjorn Gustavsson

I've tried

dbup

In the simply app1 example I've posted here previously.

It result with

"In base workspace".

and make my WS empty at all.

What does that mean? How can I get into "moose1.m" function WS where the error actually occured?

[Bjorn Gustavsson]

Well, in similar cases I just set:

dbstop in moose1

possibly with a line-number to stop at:

dbstop in moose1 at 5

and then I rerun everything with the same input - then I get the debug-prompt in that function (at line 5 (possibly also with an additional conditional)). That way, especially if you have set a good enough conditional expression for when to stop you get the debug-prompt just before the error occurs. This might be a solid bit fiddly if you have a very complex function moose1.

Best of luck.

[Bruno Luong]

"How can I get into "moose1.m" function WS where the error actually occured?"

You can't since the error of moose is embeded in try/catch block and it is retrow by the calling function. So there is no lower level in the stack when the debugger stops. You can however recall mose or invoke the callback in the try block, but this is not convenient and you are never sure too reproduce the same effect/error with your function that would not reproduce the same thing from call to call (for example if it's depend on some random generated data or persistent variable, global variable, timer, etc...).

Answer 1

[Bruno Luong]

The problem has been solved in R2022a.

Under R2021b here is the stack when debugger stops, one can see there is a dirty try/catch in the App callback engine that prevent the dbstop occurs at user level. This try/catch is no longer in R2022a App callbcak engine.

There is then no workaround for R2021b (unless modify the App calback engine AppManagementService.m but is extremely dangerous)

>> app1
>> edit moose
Index in position 1 exceeds array bounds. Index must not exceed 10.

Error in moose (line 5)
m = a(11 , 1);

Error in app1/ButtonPushed (line 14)
            moose
 
236                 throw(callbackException);
K>> dbstack
> In appdesigner.internal.service/AppManagementService/tryCallback (line 236)
In matlab.apps.AppBase>@(source,event)tryCallback(appdesigner.internal.service.AppManagementService.instance(),app,callback,requiresEventData,event) (line 37)
In matlab.ui.control.internal.controller/ComponentController/executeUserCallback (line 427)
In matlab.ui.control.internal.controller/ComponentController/handleUserInteraction (line 381)
In matlab.ui.control.internal.controller/PushButtonController/handleEvent (line 86)
In appdesservices.internal.interfaces.controller/AbstractController/handleProxyViewEvent (line 279)
In appdesservices.internal.interfaces.controller.AbstractController>@(src,event)handleProxyViewEvent(obj,src,event) (line 207)
In appdesservices.internal.interfaces.view/AbstractProxyView/notify (line 117)
In appdesservices.internal.peermodel/PeerNodeProxyView/handlePeerEventFromClient (line 268)
In appdesservices.internal.peermodel.PeerNodeProxyView>@(varargin)obj.handlePeerEventFromClient(varargin{:}) (line 81)
In viewmodel.internal.factory.ManagerFactoryProducer>@(src,event)callback(src,viewmodel.internal.factory.ManagerFactoryProducer.convertStructToEventData(event)) (line 105)
K>> ver
-----------------------------------------------------------------------------------------------------
MATLAB Version: 9.11.0.1873467 (R2021b) Update 3
MATLAB License Number: xxxxxx
Operating System: Microsoft Windows 8.1 Pro Version 6.3 (Build 9600)
Java Version: Java 1.8.0_202-b08 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode
-----------------------------------------------------------------------------------------------------
MATLAB                                                Version 9.11        (R2021b)
MATLAB Coder                                          Version 5.3         (R2021b)
MATLAB Compiler                                       Version 8.3         (R2021b)
Optimization Toolbox                                  Version 9.2         (R2021b)
Signal Processing Toolbox                             Version 8.7         (R2021b)
K>> 

Here is the same output with R2022a, it stops on moose.m

> app1
>> edit moose.m
>> dbstop if error
Index in position 1 exceeds array bounds. Index must not exceed 10.

Error in moose (line 5)
m = a(11 , 1);

Error in app1/ButtonPushed (line 14)
            moose

Error in appdesigner.internal.service.AppManagementService/executeCallback (line 138)
                callback(appOrUserComponent, event);

Error in matlab.apps.AppBase>@(source,event)executeCallback(appdesigner.internal.service.AppManagementService.instance(),app,callback,requiresEventData,event) (line 63)
            newCallback = @(source, event)executeCallback(appdesigner.internal.service.AppManagementService.instance(), ...
 
5   m = a(11 , 1);
K>> dbstack
> In moose (line 5)
In app1/ButtonPushed (line 14)
In matlab.apps.AppBase>@(source,event)executeCallback(appdesigner.internal.service.AppManagementService.instance(),app,callback,requiresEventData,event) (line 63)
K>> ver
-----------------------------------------------------------------------------------------------------
MATLAB Version: 9.12.0.1884302 (R2022a)
MATLAB License Number: xxxxxx
Operating System: Microsoft Windows 11 Home Version 10.0 (Build 22000)
Java Version: Java 1.8.0_202-b08 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode
-----------------------------------------------------------------------------------------------------
MATLAB                                                Version 9.12        (R2022a)
MATLAB Coder                                          Version 5.4         (R2022a)
MATLAB Compiler                                       Version 8.4         (R2022a)
Optimization Toolbox                                  Version 9.3         (R2022a)
Signal Processing Toolbox                             Version 9.0         (R2022a)
K>> 

Answer 2

[Matt J]

If you execute at the command line,

>> dbstop if caught error

and then rerun the app, I think you will find that the debugger stops where you want.

[Mark Golberg]

@Matt J

maybe.

problem is,

dbstop if caught error

also make the problem to stop at a whole pack of new "matlab internal issues" that I was completely transpernat to them previously. So, de-facto, it's even worst then before.

BTW, besides restarting MATLAB, any way to undo this command?

[Bruno Luong]

BTW, besides restarting MATLAB, any way to undo this command?

dbclear all

[Matt J]

also make the problem to stop at a whole pack of new "matlab internal issues" that I was completely transpernat to them previously

Don't see why that would happen, unless you have lots of your own try-catch statements in the user-supplied code.