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
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
