Windows startup issue

Richard Gaskin ambassador at fourthworld.com
Tue Nov 10 21:32:54 EST 2020


J. Landman Gay jacque wrote:

 > On 11/10/20 3:28 PM, Richard Gaskin via use-livecode wrote:
 >> But at the time it seemed to me the tool was for edge cases where one
 >> might encounter raw error data with no UI.  It never occurred to me
 >> to ship an application without error handling, and
 >> back then I'd never used LC's so I just assumed it was at least as
 >> good as my own.
 >
 > We shouldn't confuse our own error handling with compiler errors. I
 > include extensive logging and error reporting when "the result" or
 > something similar in my scripts fail. As developers,
 > it's our job to do that.

Of course, which is why I've not been able to find the recipe for seeing 
these lists of error info people keep mentioning here and in the forums.

But given the number of times they're cited, it's clear a lot of people 
are encountering them unexpectedly.


 > The cryptic numbers only occur when a compiler error happens. A well-
 > tested stack won't have many of those by the time it's distributed.
 > The one in question here is an odd one-off which only happened for
 > one user.

Compiler errors or execution errors?

If this is limited to compiler errors I'm wondering what went wrong 
earlier in the workflow that so many people are able to close their 
scripts and move on without noticing that the Script Editor has been 
trying to get their attention, and that the scripts don't run at all 
until they're compiled.

The Dictionary says compilation errors are only reported in "the result" 
after an unsuccessful attempt to set the script of an object (apparently 
the old scriptParsingError message is no longer sent, though oddly 
enough a handler for it remains in the IDE).

Do we have that many people writing self-modifying code?


Execution errors are what I was referring to in my last post.

As thorough as we may be, in any sufficiently complex code base there's 
likely to be some error condition we didn't explicitly code for.

Our choices are to handle those ourselves with an errorDialog handler, 
or remember to click the checkbox in the Standalone Builder to use LC's 
Execution Error reporting stack.

If you don't do either, errors fail silently (at least when I just 
tested it here with a simple test stack).

But oddly, when I include LC's Execution Error dialog, the result was, 
shall we say, not as expected:
http://fourthworld.net/lc/lc-err-dialog.png

That's in v9.6.1. Their exec err stack used to work. I wonder when it broke.


So for exec errors, at a minimum it would be very helpful to have the 
Execution Error reporting window option set to be included by default in 
new standalones, so that it can become possible for folks to know what 
happened when behavior starts getting wonky.

Later on I have a wish list of improvements for that dialog, but having 
some means of knowing when an error occurs in a form suitable for 
end-users seems a reasonable minimum to expect.


Hard to say what's in play in this thread (and perhaps others like it) 
where the only reported symptom is a list of error info, since Marty's 
description was:

    "The errors show up in a dialog window."

Is that an answer dialog?  Is that an LC lib that does that, something 
Marty wrote, or...?

How can I get a standalone to show me a list of error info like that?

Whatever that recipe is, that's the thing we'll want to fix.



 > So it sounds like you're asking LC to translate its compiler errors
 > in standalones. These are infrequent enough for me that the numbers
 > aren't much of a concern; they largely happen during development and
 > those are translated for us. But Paul's suggestion that standalones
 > include the entire error list isn't a bad one, though I'd like it to
 > be optional.

It looks they did that some time ago - kinda.  The revIDELookupError 
function in "revIDELibrary" includes this tantalizing line:

     get line tCode of the scriptExecutionErrors

So it looks like a built-in function now, right?

Not quite: doesn't work in a standalone.

I'm guessing they copy the latest value that returns into their 
Execution Error dialog when you add that checkbox, so custom things can 
do the same. Still an extra step, but much easier than the old method we 
used to use of having to remember which custom property - and before 
that, which hidden field -- of which stack that list was stored in.

But that's for seasoned pros willing to roll their own.

First we need to figure out how people are unexpectedly seeing lists of 
raw error info and turn that into a more useful experience.

Then we can look at enhancing LC's Execution Error dialog, and have the 
default be on rather than off.

After that there are a hundred other paper cuts, but let's see if we can 
knock these off first.

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






More information about the use-livecode mailing list