Thread Subject: Error lands in debugger instead?

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.

"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

"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?

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

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.

"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.

"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

"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.