MATLAB Central Newsreader - Error lands in debugger instead?

Error lands in debugger instead?

Fred Sigworth — Tue, 09 Oct 2007 13:59:22 -0400

Is there a better way to debug code? I run my program, and it halts with an
error. Then I click on the error statement, go to the editor, set a breakpoint,
and run the program again, this time to halt it so I can look at the variables.

Why can't a fatal error put me directly into the debugger, as if the program
encountered a breakpoint? Then I could select which stack frame I wanted, and
look at the variables directly.

Re: Error lands in debugger instead?

Steven Lord — Tue, 09 Oct 2007 14:13:11 -0400

"Fred Sigworth" <fsigworth@mac.com> wrote in message
news:feg1fq$ptf$1@fred.mathworks.com...
> Is there a better way to debug code? I run my program, and it halts with
> an
> error. Then I click on the error statement, go to the editor, set a
> breakpoint,
> and run the program again, this time to halt it so I can look at the
> variables.
>
> Why can't a fatal error put me directly into the debugger, as if the
> program
> encountered a breakpoint? Then I could select which stack frame I wanted,
> and
> look at the variables directly.

Look at "Error Breakpoints" on this page:

http://www.mathworks.com/access/helpdesk/help/techdoc/index.html?/access/helpdesk/help/techdoc/matlab_env/bq4hw4g-1.html

If you want to enable this behavior at startup, use DBSTOP in your startup.m
file as described in the last paragraph on that page.

--
Steve Lord
slord@mathworks.com

Re: Error lands in debugger instead?

Darik — Tue, 09 Oct 2007 16:21:08 -0400

"Steven Lord" <slord@mathworks.com> wrote in message
<feg29n$ag6$1@fred.mathworks.com>...
>
>DBSTOP IF ERROR
>
>SNIP

What about something like this:

h = figure;
prop = schema.prop(h, 'MyProp', 'mxArray');
prop.SetFunction = @mySetFunction;
set(h, 'MyProp', 'test')

function val = mySetFunction (h, evt, val)

%code culminating in error
error ('mySetFunction', 'Error occurred setting property
MyProp')

Using dbstop if error will result in the debugger stopping
at the SET command, not at the line in the set function
causing the error. Does anyone know if there's a way to
have the debugger stop in the set function?

Re: Error lands in debugger instead?

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) — Tue, 09 Oct 2007 17:28:10 -0400

In article <feg9pk$95b$1@fred.mathworks.com>,
Darik <dgambleDEL@uwaterlooDEL.caDEL> wrote:
>Using dbstop if error will result in the debugger stopping
>at the SET command, not at the line in the set function
>causing the error. Does anyone know if there's a way to
>have the debugger stop in the set function?

set() is normally a built-in function, not coded in matlab.

--
"Okay, buzzwords only. Two syllables, tops." -- Laurie Anderson

Re: Error lands in debugger instead?

Darik — Tue, 09 Oct 2007 18:33:44 -0400

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote in
message <fegdna$aeu$1@canopus.cc.umanitoba.ca>...
> In article <feg9pk$95b$1@fred.mathworks.com>,
> Darik <dgambleDEL@uwaterlooDEL.caDEL> wrote:
> >Using dbstop if error will result in the debugger
stopping
> >at the SET command, not at the line in the set function
> >causing the error. Does anyone know if there's a way to
> >have the debugger stop in the set function?
>
> set() is normally a built-in function, not coded in
matlab.
>
> --
>

Yeah, I know. Using schema.prop to add custom graphics
properties is an undocumented feature. In the code snippet
I posted, the built-in SET function calls the user defined
function mySetFunction.

Re: Error lands in debugger instead?

Darik — Tue, 09 Oct 2007 18:53:51 -0400

"Darik " <dgambleDEL@uwaterlooDEL.caDEL> wrote in message
<feghi8$mnu$1@fred.mathworks.com>...
> roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote in
> message <fegdna$aeu$1@canopus.cc.umanitoba.ca>...
> > In article <feg9pk$95b$1@fred.mathworks.com>,
> > Darik <dgambleDEL@uwaterlooDEL.caDEL> wrote:
> > >Using dbstop if error will result in the debugger
> stopping
> > >at the SET command, not at the line in the set
function
> > >causing the error. Does anyone know if there's a way
to
> > >have the debugger stop in the set function?
> >
> > set() is normally a built-in function, not coded in
> matlab.
> >
> > --
> >
>
> Yeah, I know. Using schema.prop to add custom graphics
> properties is an undocumented feature. In the code
snippet
> I posted, the built-in SET function calls the user
defined
> function mySetFunction.

Sorry, just realized I wasn't as clear here as I should've
been. I'd like the debugger to stop at the line in
MYSETFUNCTION that causes the error, NOT earlier in the
stack in the parent function that calls the SET function.

Re: Error lands in debugger instead?

Yair Altman — Tue, 09 Oct 2007 19:43:15 -0400

"Darik " <dgambleDEL@uwaterlooDEL.caDEL> wrote in message
<feginv$gp1$1@fred.mathworks.com>...
> "Darik " <dgambleDEL@uwaterlooDEL.caDEL> wrote in message
> <feghi8$mnu$1@fred.mathworks.com>...
> > roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote in
> > message <fegdna$aeu$1@canopus.cc.umanitoba.ca>...
> > > In article <feg9pk$95b$1@fred.mathworks.com>,
> > > Darik <dgambleDEL@uwaterlooDEL.caDEL> wrote:
> > > >Using dbstop if error will result in the debugger
> > stopping
> > > >at the SET command, not at the line in the set
> function
> > > >causing the error. Does anyone know if there's a way
> to
> > > >have the debugger stop in the set function?
> > >
> > > set() is normally a built-in function, not coded in
> > matlab.
> > >
> >
> > Yeah, I know. Using schema.prop to add custom graphics
> > properties is an undocumented feature. In the code
> snippet
> > I posted, the built-in SET function calls the user
> defined
> > function mySetFunction.
>
> Sorry, just realized I wasn't as clear here as I should've
> been. I'd like the debugger to stop at the line in
> MYSETFUNCTION that causes the error, NOT earlier in the
> stack in the parent function that calls the SET function.

Schema.prop handlers only receive the object handle and
suggested value as their first 2 args - no evt field. They
also have a generic try-catch mechanism that causes errors
to propagate upward to their caller (=your set call), which
is why you dbstop there. You can trick this by having your
own error-handling code segment, as follows:

function val = mySetFunction (h, val)
  try
    % do something
  catch
    err = lasterror;
    keyboard; % inspect err struct here
  end

BTW, you can specify additional handler params, as follows:

prop.SetFunction = {@mySetFunction,data1,data2};
...
function val = mySetFunction(prop,val,d1,d2)

All this is (as stated above) entirely undocumented and
unsupported. You can see some usage ideas in a few of my
File Exchange submissions
(http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=14583
for example).

Yair Altman
http://ymasoftware.com

Re: Error lands in debugger instead?

Darik — Tue, 09 Oct 2007 21:08:41 -0400

"Yair Altman" <altmanyDEL@gmailDEL.comDEL> wrote in message
<feglkj$st2$1@fred.mathworks.com>...
>
> Schema.prop handlers only receive the object handle and
> suggested value as their first 2 args - no evt field. They
> also have a generic try-catch mechanism that causes errors
> to propagate upward to their caller (=your set call),
which
> is why you dbstop there. You can trick this by having your
> own error-handling code segment, as follows:
>
> function val = mySetFunction (h, val)
> try
> % do something
> catch
> err = lasterror;
> keyboard; % inspect err struct here
> end
>
> SNIP

That'll work!

I was just writing the example set function from memory,
which is why I messed up the function header. I've actually
learned everything I know about schema.prop objects from
your various posts here on the CSSM, so consider this my
much overdue thanks.