errorDialog Problem

WaltBrown · Post by **WaltBrown** » Sat May 30, 2009 5:39 am

I have an odd problem with errorDialog. I have a script (simplified for this discussion) that goes thru a list of property names to get their current values. When I call some, though, I get an error (at the "do it" point), which I want to catch, then continue on. So I wrote this:

Code: Select all

on mouseUp
   put 0 into sTestLinesCompleted
   send runTests to me
end mouseUp

on runTests
   repeat with sLineNum = (sTestLinesCompleted+1) to sTotalTestLines
      put line sLineNum of field fTestWords into sTestWord
      add 1 to sTestLinesCompleted
      send firstTest to me
   end repeat
end runTests

on firstTest
   put 1 into sTestNum
   put "get "&&sTestWord into it
   do it                                     // Error here kills this handler
   put it into sValueReturned
   send secondTest to me
end firstTest

on secondTest
   put 2 into sTestNum
   put "get the"&&sTestWord into it
   do it                                     // Error here kills this handler
   put it into sValueReturned
end secondTest

on errorDialog pExecutionError, pParseError
   put line (item 1 of line 1 of pExecutionError) of the cErrorsList of card 1 of stack "revErrorDisplay" into sErrorReturned
   if (sTestNum = 1) then
      send secondTest to me
   else
      send runTests to me
   end if
end errorDialog

What happens is that the first time errorDialog occurs, everything is fine, and I continue on with my list of tests. The second time, though, that errorDialog SHOULD be hit, the code freezes. It seems I am only getting one errorDialog message per mouseUp.

Any thoughts? For a while I thought it was some kind of race condition, but after experimenting with waits it doesn't seem to be the case.

Thanks, Walt

Mark · Post by **Mark** » Sat May 30, 2009 9:33 am

Dear Walt,

If I understand you correctly, you are causing an error inside the errorDialog handler, after an execution error already occurs. As a result, another execution error occurs. As a result, your scripts get stuck in an endless loop, which may give you the impression that Revolution is frozen. Because pressing command-period causes another errorDialog message, aborting the endless loop causes another endless loop, which causes you to be really stuck.

Your script starts with mouseUp. This calls runTests. RunTests calls firstText, which causes an error. The error calls errorDialog, which calls runTests again, because sTestNum is never 1. The runTests causes an error et cetera.

It seems that you have no local variables explicitly defined. If you add a line to the top of your script, containins

Code: Select all

local sTestNum,sErrorReturned

the handler secondTest may run once. However, secondTest causes another error, which still causes you to get stuck in an endless loop, because the third time that your handler runs, runTests will be called again.

Another fun thing is that your endless loop may cause a recursion error, which triggers the errorDialog handler, whicih gets you in yet another endless loop. By now, you'll probably understand that deliverately causing errors from within the errorDialog handler is not a good idea. You should always put the code of the errorDialog handler inside a try control structure, to makek sure that it doesn't cause any additional errors.

Code: Select all

on errorDialog
  try
    -- your code here
  catch myErr
    put myErr --show additional problems in message box in IDE
  end try
end errorDialog

Best regards,

Mark

WaltBrown · Post by **WaltBrown** » Sat May 30, 2009 2:38 pm

Thanks Mark. I don't think I am causing an error within the errorDialog handler, I am just using it to send a message to the two handlers that could incur the error - I had assumed it exits the errorDialog and then the other handlers handle the message sent by errorDialog.

That implies errorDialog stays on the "stack". Is that actually true?

So it begs the question - if I send a message, does the original handler wait around for a result?

Of note is that after the errorDialog sends the message to runTests or firstTest, if they don't incur a second error they run successfully, it is only the second call to errorDialog which fails, but that could be after some number of successful iterations.

Thanks,
Walt

Mark · Post by **Mark** » Sat May 30, 2009 2:52 pm

Hi Walt,

Yes, you ARE causing an error within the errorDialog handler, as I explained.

I don't know what you mean by "stays on the stack".

Yes, handlers wait for a result, unless you use the form "send <message> in <integer> millisecs".

Best,

Mark

WaltBrown · Post by **WaltBrown** » Sat May 30, 2009 3:04 pm

Thanks Mark. "Stack" is an unfortunate use of a standard term in this context, I should have said in the "message queue" or "execution stack".

I tried the "send msg in 1 tick" - that improved it to the point where it executes the errorHandler about 5 times (and the tests about 20 times) before it halts again.

I want to drill into your comment about causing an error "inside" the errorDialog handler - the errors are caused by the "do it" instruction in the other handlers, not "in" the errorHandler. Maybe it's my misunderstanding - your comment implies that the errorDialog handler ends up "inside" the other two (ie the test handlers pause execution at the error rather than exit)? (That's why my comment about the message queue).

Sorry for beng possibly dense, I am trying to understand the execution architecture. I also added an "exit errorDialog" after the send.

Thanks again,
Walt

WaltBrown · Post by **WaltBrown** » Sat May 30, 2009 3:10 pm

OK, fyi, just ran another test. If the test handlers incur an error, they do NOT return after the error, the error terminates their execution at that point and they never return, so they are not staying on the execution stack, and also implying the errorDialog handler does not run "inside" the contexts of the test handlers.

Walt

Mark · Post by **Mark** » Sat May 30, 2009 3:19 pm

Walt,

If you try to understand the execution architecture, then read up on the subject "message hierarchy". Do a search in this forum and read the conference stack about that subject. Doing theoretical exercises with the errorDialog message won't help you.

The errorDialog calls another handler, which in turn causes an error. That's why I say that you're deliberately causing an error "within" the errorDialog handler, which causes an endless loop and hence doesn't make any sense whatsoever.

Best,

Mark

WaltBrown · Post by **WaltBrown** » Sun May 31, 2009 12:24 am

Thanks Mark, I read up on that. Plus, thanks for that link, I hadn't seen those online conferences yet.

The issue is that I do want to do operations that could incur errors (since errors are one valid response during a test strategy), so I am trying to see how to do so without making them either recursive or fatal - I want log them and continue testing after an error. I will experiment some more with the send, send in <x ticks>, and the call function.

BR, Walt

mwieder · Post by **mwieder** » Sun May 31, 2009 12:50 am

You might want to use a try/catch construct for your tests instead of writing your own errorDialog handler - something like:

Code: Select all

try
  do it
catch e
  handle your error here
end try

WaltBrown · Post by **WaltBrown** » Sun May 31, 2009 1:04 am

Thanks. Mark had also suggested that earlier, that was going to be my next attempt - I had to read up on "catch" and "try" first

Walt

mwieder · Post by **mwieder** » Sun May 31, 2009 1:12 am

Well, yes, but on rereading Mark's post, he was suggesting putting the try/catch stuff inside the errorDialog handler. I'm suggesting *not* using your own errorDialog routine, for a couple of reasons. First of all, having looked through the way the rev IDE handles errors, I think this is the wrong approach - there's interaction between the IDE and the rev engine in handling errors, and you need to be doing everything right or you'll end up in some endless loops (I guess I don't need to tell you about that part). Secondly, the errorDialog message *should* really only be triggered if the debugger is turned off, and that may affect your tests as well.

That said, I do (I think) understand what you're trying to do here and I wholeheartedly approve of being able to set up test conditions and run them in a controlled way.

WaltBrown · Post by **WaltBrown** » Sun May 31, 2009 1:54 am

That worked perfectly, thanks.

mwieder · Post by **mwieder** » Sun May 31, 2009 2:01 am

Cool. Glad it worked out. I set up a test suite runner program a while back for my own stacks using that sort of arrangement and it's been working quite well for me.