step in debugger?

[J. Landman Gay]

Charles Hartman wrote:
> Thanks. No, that twist on it I had recognized -- so if I need a  
> breakpoint-and-step at the end of a handler, I put in a "put 0 into  
> tDummy" line at the end.
> 
> In this case, the breakpoint line is in the middle of the handler, in  
> the middle of a repeat loop or a 'try' structure. (Now I can't  remember 
> which handler I was debugging yesterday when I finally  noticed this! 
> though I know it's happened before.)
> 
> Is it possible that "try" doesn't mix right with breakpoints and  
> "step"? But I know I noticed step misbehaving when there *wasn't* a  
> problem in the code, so it's not a matter of the "try" having kicked  me 
> out into the "catch". (And in that case, shouldn't "step" take me  to 
> the first line of the "catch" anyway?)
> 
> I hope this makes more sense. I *think* this was the code I was  debugging:
> 
>     repeat for each line tLine in fld "playerListFld"
>         if tLine is not empty then
>             put empty into tPlayerRecToStore
>             put word 1 of tLine into tPersonID
>             put tPersonID into tPlayerRecToStore["personID"]
>             put tPerformanceID into tPlayerRecToStore["performID"]
>             -- apparently no good way to "batch" store all these  records
>             try
>                 get libdb_addToTable(gDB, "players",  tPlayerRecToStore, 
> "personID")
>             catch errMsg
>                 put false into storeOK
>                 handleDatabaseError errMsg
>             end try
>         end if
>     end repeat
>     select text of fld "playerListFld"
>     [and so on . . .]
> 
> with the breakpoint on the "get libdb_ . . ." line.

This sounds like the problem we have discussed before, where if there is 
an error in a function or handler call and the breakpoint is set in the 
calling handler, the debugger will simply run to the end and/or exit. 
This is preferable to MetaCard's debugger behavior, where the problem 
causes infinite, recursive error messages and you have to force-quit.

I suspect there is a problem with the libdb_addToTable call. If you 
comment out that line and you see normal debugging behavior, then that's 
what is going on.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com