Something strange...

[dunbarx]

say cmhjon develops on a mac, where the symbol Klaus points out is acceptable for use. The IDE will just run it and show no errors, wouldn't it? I

Absolutely. Which is why we must test the standalones just as exhaustively as the development stacks. I assume that standalones are not delivered unless the IDE stacks (Seem to be? Hoped that they are? Prayers are said for them to be?) bug free.

Craig

[bogs]

Oh Craig, I'm sorry, I think I misunderstood what you were saying. When I saw this part :

At least in the IDE, there are powerful tools that tell you where to look.

I thought maybe there was something (amidst the metric TON of stuff) I was missing on how to test the command cross platform from the IDE itself My bad, and deepest apologies, I think I get it now.

[dunbarx]

Hi.

What I really meant was that if something goes awry in the IDE, the debugger will step in at once, execution halts at the line of interest, and with clear indications (usually) of what happened and where to examine the situation.

Thank heaven.

In a standalone, the process simply ends silently, especially with runtime errors, and it is much harder to figure out where to start and what to work on.

Craig

[bogs]

Yup, I get it now, and with a few lines of error checking code in place in the standalone (while testing on other os's) you should be able to catch those bugs before final deployment. Something along the lines of

Code: Select all

try
   [code]
catch [Err]
   put [Err]
end try

or even if / then or case statements to make sure your getting what you expect.

[dunbarx]

Bogs.

Right on with catch/try. That is the way to see what is going on in a standalone. But that means you are already suspicious of certain segments of your code. This is a good thing.

In the IDE, I just plop down any old stuff and see what blows up. That is called brutish programming. I invented that.


Craig

[bogs]

In the IDE, I just plop down any old stuff and see what blows up. That is called brutish programming. I invented that.

And I am one of the chief adherents to it

Curious about that catch / try in Lc, it doesn't catch custom code errors? Not sure I followed the dictionary entries correctly, way I read it either custom props or is it just any custom variable it doesn't catch?

[dunbarx]

Anything that would engender an error in the IDE will set the errorVariable with an error message. This sort of event might be ignored in a standalone if, say, it was a runtime error of the sort:

"no such object..."

Like if you tried to put data into a non-existent field.

Code errors, as you wrote, will not compile ("compile-time" errors). These are easy to fix. It is the other kind, environmental errors, that can kill you, since these do in fact compile. You might say that the "≠" character was neither a compile-time error, nor, at least in the Mac IDE, a run-time error.


We are back to testing standalones wherever they might live.

With the "try/catch/finally" structure the standalone can now report what went wrong.

Practice on a small stack with a button that does something outlandish, but contains the structure. Include a non existent handler call, if that is what you meant by "custom". Making standalones will only take a few seconds.

Craig

[jacque]

Another way to catch errors is to write an errorDialog handler and have it report the information it gets. This is a generic solution that doesn't require changing the scripts to accommodate error reporting. It doesn't catch everything, but it will report any errors sent by the LC engine. See errorDialog in the dictionary. I usually report all the info it contains because that gives you the name of the object containing the script:

Code: Select all

on errorDialog pExecutionError
    answer pExecutionError
end errorDialog

[bogs]

Oh now that is just too slick and here I was, inventing new and elaborate handlers for such things

[jacque]

Note that when errorDialog reports an error, it will give you engine error codes rather than English translations. You'll want to look those up. Richard and I wrote a tool to make that easier, search the Sample Stacks area (in the LC toolbar) for "LiveCode Error Lookup".

[bogs]

Jacque, I noticed almost immediately that I didn't know what I was looking at in the errorDialog report but I was determined to get to understand its workings !

My first playing around with it, I actually couldn't get one pre-determined error to come to mind (probably a first for me, usually I can think of TONS!).
As I sat there thinking, I finally remembered that dividing by 0 is usually a good one, so I wrote the following:

Code: Select all

// for later use in the demo...
local tmpVarOne, tmpVarTwo

on errorDialog pExecutionError, pParseError
// put the complete error in the field for study...
put cr & "An error occurred on line: " & pExecutionError & cr before field "txtErrorReport" 
/* in the dictionary, it says parseError is deprecated, adding it in the put statement produced no difference in the output, so not sure if it is already part of it or not...*/
end errorDialog

on openCard
 // will later be setting up multiple error situations that will run for each button click...
    set the label of button "cmdInitiate" to "Error 1"
end openCard

on mouseup
// yes, I know the following can be shortened immensely...
    if word 1 of the target is "button" then
        if the label of the target is "Error 1" then
            put 12/0 into tmpVarOne
            put tmpVarOne into field "txtErrorParsed" 
        end if
    end if
end mouseup

/* initially tried 'put 12/0 into field "txtErrorParsed" but for some reason this was just skipped in the debugger. 
In the script debugger it automatically catches the error, giving this result - 
card id 1002: execution error at line 15 (Operators /: divide by zero), char 1   */

In the dictionary entry on it, it also says -

Note: The errorDialog message is only sent while Script Debug mode is turned off. To toggle Script Debug mode, click on the Development menu of LiveCode's menubar.

I take this to mean this would really be ideally used in a standalone, but does it catch things the script debugger would not?

If someone else new to Lc uses the routine, which really is a nice simple short way to find an error, the full output of errorDialog looks like this -

An error occurred on line: 379,15,17
465,15,1
253,14,1
253,13,1
241,13,1,mouseup
353,0,0,card id 1002 of stack "~/Lc_Projects/Lc601Projects/errorDialogDemo/errorDialogDemo.livecode"

I would certainly suggest using the answer dialog to get the parts of the result you want, or put the field on a card that only gets called if an error happens, or even log it to a file if you want it returned by your testing team

Needless to say, I certainly will be looking up the sample stack you and Richard wrote

I also found the following entries in the dictionary to be of interest to me on this topic and will be exploring them further -
errorMode, errorObject. scriptExecutionError, and sysError. I really can't thank you enough for setting me on the path

Edit -
Oh that Lookup plugin is a TREAT!

LiveCode Error Lookup_001.png (11.2 KiB) Viewed 8963 times

[jacque]

I take this to mean this would really be ideally used in a standalone, but does it catch things the script debugger would not?

It catches the same things, and it's what the IDE uses too. If debug mode is on, the IDE translates the error for you and opens the script for debugging. I do find errorDialog very useful in standalones where there are few ways to know what went wrong.

The sysError is useful because it will tell you errors coming from the OS, though generally those are more rare. The other keywords mentioned are mostly only useful if you are writing a debugger, and are used by the script editor.

[bogs]

Very good to know! Writing a debugger... hmmmmmm...