LiveCode Forums.

-
LiveCode's error messages are often difficult to interpret or incomprehensible.

I wonder if there is a way where end-users could contribute error messages on-the-fly?

Or, at least into some sort of online repository, where, after suitable "triage" they could
be rolled into the next LiveCode release.

richmond62 wrote: ↑

Sun Jul 07, 2019 7:24 pm

I wonder if there is a way where end-users could contribute error messages on-the-fly?

If we could, I could just see the first 10 being "bogs opened the IDE and..." variations

I seem to remember Richard (or Jacque) pointing me to a stack that had some kind of decryption for Lc errors, but it has been so long since I looked at it, I've forgotten what it was

At one point one could add notes to the Dictionary which would then
spread through the "LiveCode Universe" like that funny theory put forth by
Anaxagoras that we are descended from seeds that blew here via a sort
of interstellar wind.

I seem to remember Richard (or Jacque) pointing me to a stack that had some kind of decryption for Lc errors, but it has been so long since I looked at it, I've forgotten what it was

It could have been either of us, we wrote it together. In the User Samples, search for "LiveCode error lookup" and it should show up.

richmond62 wrote: ↑

Sun Jul 07, 2019 7:24 pm

I wonder if there is a way where end-users could contribute error messages on-the-fly?

I base error-handling code on the content of error messages. Many do. Any revisions to those strings needs to be carefully considered.

Do you have an actual example of a mystifying string? Maybe the opportunity here is for a different mechanism altogether, one that can enhance work in the IDE without altering runtime. Some practical real-world use-cases may point the way.

Or, at least into some sort of online repository, where, after suitable "triage" they could
be rolled into the next LiveCode release.

Done:
https://github.com/livecode/livecode

...and in particular engine/src/executionerrors.h

But you *could* go through the process of intercepting the ErrorDialg message and in your script convert the terse built-in messages to ones of your own.

There are, of course, several error messages that could do with some translation.
Gotta love #526 "bad family expression". I can think of a few of those myself.

mwieder wrote: ↑

Tue Jul 09, 2019 1:01 am

Gotta love #526 "bad family expression". I can think of a few of those myself.

How does one trigger a 526 error?

...well, anecdotally it would happen around Thanksgiving dinner...

mwieder wrote: ↑

Tue Jul 09, 2019 6:46 am

...well, anecdotally it would happen around Thanksgiving dinner...

... or anytime I see my sisters longer than it takes to wave my hand...

I'm guessing it has to do with the limited support LC provides for HC's "families" of buttons, the mechanism for syncing radio buttons IIRC, which we do with groups in LC.

But coming to LC from a SuperCard background (I pretty much stopped using HC the day SC was released), my memory of HC's features has faded, and I've almost never used any of the LC language features specific to HC. So take my guess with a grain of salt.

Here's a real "horse chestnut" that happened to day in a class with absolute beginners on day 2,
trying to construct "function machines" in LiveCode:
- -
( to a certain extent this is because, while I learnt about these in 1971
- when I was 9 - here in Bulgaria they don't learn about them unless
they study programming at University! )
-
Now one of the boys set up his stack:
- -
with the following code in button "f1'
-
and the thing "threw" this back at him:
- -
button "Button": execution error at line 3 (pow: error in left operand), char 1

It took me 30 minutes to determine the problem was NOT in the script at all (why should it be?)
but owing to a mistake the field "fINPUT" contained two numbers separated by a carriage return
which we could not see because the field was too short.

I am honestly not quite sure how a newbie programmer would have worked that out at all as the error message appeared to refer to the script and NOT something about the contents of a field.

That's a good example. The LC engine is doing what we would expect there: having already obtained the value of ZZ from a field, in line 3 it has no awareness of the field at all, simply operating on ZZ.

Had ZZ been passed in as a param from a separate handler which derived its value from a field, the job would be harder to trace back to the origin of ZZ's value.

As a human, we can look at the code and figure out how ZZ is loaded. If we could translate that into a static analysis function, we could craft a debugger add-on to provide such guidance.

What would be the algorithm for such an analysis? What would a human need to do, and how might we express that in code?

That is indeed a good example.

In the first place, I'm annoyed that xtalk allows the use of keywords as object names, but that's a different rabbit hole. And a different rabbit.

I would say that "pow: error in left operand" does not give nearly enough context for the error. And this isn't just a matter of changing the error text: given the context I'd like to see as a start an error message that explains that there is a non-numeric character in variable ZZ. That would at least give someplace to start looking.

Better than that would be a statement of which character couldn't be parsed.
And ideally a way to walk back the execution trail to see how that character got into ZZ

So->

execution error at line 3: non-numeric character in variable ZZ
character is crlf, 0x0D hex, 13 decimal
execution context:
mouseUP: line 1: put fld "fINPUT" into ZZ
mouseUP: line 3: put ZZ^2 into Z2

I would jalouse "pow" refers to 'power', as in 'XX^2',
but that is not exactly transparent, especially for newbies.
- -
Leeze me on your curly pow
My ain dear Dainty Davie.

Well worth til clap thon lugs til for a wee bit meenit:

https://www.youtube.com/watch?v=QNsR0BHYUj8

mwieder wrote: ↑

Tue Jul 09, 2019 11:45 pm

I would say that "pow: error in left operand" does not give nearly enough context for the error.

You mean something like this for narrowing it down -