errorDialog broken?

[Richard Gaskin]

Mark Waddingham wrote:

 > On 2016-04-13 22:46, Richard Gaskin wrote:
 >> Ralph DiMola wrote:
 >>
 >>> It works in a library stack. In fact it also catches IDE errors.
 >>
 >> Thanks.  I found the culprit:  I hadn't yet turned off "Debug Mode"
 >> (still don't know why the default is to create yet one more
 >> difference between IDE and runtime, but oh well...)
 >
 > Perhaps because the assumption is that most people when using a dev
 > tool will actually want interactive debugging by default ;)

You might think so, until the user explicitly expresses a desire to 
handle the errorDialog message themselves by writing an errorDialog handler.

But that's just a design decision.  What seems obvious to you or to me 
or anyone else may differ from time to time.  That's ok.

The weird part is how it works - or perhaps doesn't work:

I have this in a button:

on mouseUp
    throw "Some random message"
end mouseUp

...and this in the stack script:

on errorDialog
   put the params
end errorDialog

My stack's errorDialog message never triggers, but the one in 
revbackscriptlibrary does.

That seemed weird to me, so I thought perhaps one of the debug messages 
is trapping something else and explicitly sending "errorDialog", so I 
added this to the errorDialog handler in revbackscriptlibrary just below 
the handler declaration (which was in itself an odd exercise - 
<http://quality.livecode.com/show_bug.cgi?id=17400> ):

    put the executionContexts

What I get in the message box is just two lines:

- the errorDialog handler in revbackscriptlibrary
- mouseup from the button that starts the execution path.

What could cause all other scripts to be bypassed to favor one 
particular backscript?


This was interesting:

 > That being said, there is a bughancement (I can't quite decide
 > whether it should be considered a bug or not - it is how the
 > engine's debugger has always worked after all) here to have
 > throwing of errors work the same way in the debugger as other
 > dev tools. i.e. The debugger should break when a throw occurs,
 > but then not actually interrupt normal processing when you
 > continue to execute.

Doesn't sound related to what I'm seeing with the odd message path for 
errorDialog - could it be?

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com