Debugger Trouble!

[J. Landman Gay]

David Burgun wrote:
> Hi,
> 
> The debugger has suddenly stopped stopping on breakpoints! It doesn't 
> stop even if I hard code a "breakpoint" into the script! What is the 
> probably cause of this and how can I get the debugger to stop on 
> breakpoints?

I have been struggling with the same thing. It is difficult to get 
around it.

When a script contains two errors, the Rev debugger simply exits. The 
handler then runs to the end without stopping (or appears to) and no 
breakpoints are acknowledged. The exit behavior is there to prevent a 
recursive error dialog that you wouldn't be able to cancel -- so in a 
way, the current behavior is good. However, it does interfere with 
debugging.

If I run the same script in MetaCard, which does not have this forced 
exit behavior, I do get a recursive error that freezes up the app and 
requires a force-quit. However in MetaCard I can usually debug right up 
to the first error condition so that at least I know where in the script 
I should be looking for a problem. Revolution exits earlier and its 
error dialog is often blank. MetaCard's error dialog contains relevant 
error messages, but flashes between the two so rapidly that they are 
hard to read, and of course, you can't fix the error until you have 
force-quit and relaunched.

One thing you may be able to do, if your scripts are written in a way 
that supports it, is to comment out all handlers except for the 
immediate one you are testing. If that one runs okay, uncomment another 
one. Keep going till you can at least isolate the handler that has a 
problem.

I see this most often if a handler with an error calls another handler 
that also has an error. For example:

on test
   put "abc" into myString
   add 1 to mystring -- error condition
   get doSomething(myString)
end test

function doSomething aString
   add 2 to aString -- second error condition
   return aString
end doSomething


In this example, a breakpoint set in handler "test" will not break (if I 
have figured this out right, I'm still kind of hazy on exactly what 
makes the problem happen.) The handler will then run to the end using 
incorrect data, or will appear to run but not really produce anything. 
I'm still trying to pin this down exactly.

These things are very difficult to debug. Your best bet may be to just 
examine the scripts carefully to see if you can spot either error 
condition and fix it.

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