When compiled, how to know which line is error

[michaelslamet]

When our compiled script error, how to know which line that caused that error?

[czardas]

That depends on the type of error. If the error causes the interpreter to crash, I don't know a solution. If it is an exception you expect to occur, you could code for it using @ScriptLineNumber. You should first test everything thoroughly before compiling to avoid errors anyway.

Edit

Strike out

Edited June 22, 2013 by czardas

[water]

Add error checking code to your script and test, test, test to find as much errors as possible before you use the script in production.

[michaelslamet]

@czardas: thanks @ScriptLineNumber macro, I will look at it.

@water and czardas: yes, I will But nobody know's what will happen in the future, let say when the PC upgrade the OS or upgrade the service pack or anything else

[czardas]

I just realised that @ScriptLineNumber doesn't work with compiled scripts. I'll test it and see.

Edit

I was right, it's no use - sorry for the misinformation.

Edited June 22, 2013 by czardas

[water]

The subject @ScriptLineNumber in compiled scripts has been discussed many times. The forums search feature is your friend

[michaelslamet]

No problem, czardas, thanks for trying to help!

So there is no way?

[czardas]

So you have to hard code the line numbers if you want to know where an error occurs when compiled using something like this.

Global $sLine1 = "Line 1"
SetError (1) ; Error induced for the demo
If @error Then
    MsgBox(0, "", "Error occured at line 2")
    Exit ; or do something else
EndIf

Edited June 22, 2013 by czardas

[michaelslamet]

Unfortuntely for my scenario at this moment, it cant be done that way, because:

1. the script is 1000++ lines.

2. the error occure sometime, sometime not.

It only throw an error when run as compiled and never when run from SciTe

[TheSaint]

This brings to mind the question, of why you would want to know, if the source script is no longer available to you?

Surely, if the uncompiled script is available, you would always want to test with that, even doing compiles as needed during troubleshooting.

Else, you should always code you programs to return errors at diligent/smart sections. One should never make presumptions when coding or rely on something not changing, so you should cater for most possibilities.

[michaelslamet]

@TheSaint: I have the source script with me It only throw an error when run as compiled and never when run from SciTe

Thanks!

[TheSaint]

Missed your last post #9.

One way, that I sometimes use, is to have certain values and returns, saved to a log file, that you can check if need be ... which can even be a ini file if desired. This method is especially useful where dialogs or SciTE is not helpful, etc.

Edited June 22, 2013 by TheSaint

[czardas]

Let's imagine the scenario that you used a macro such as @ScriptLineNumber in your code. When not compiled the value for @ScriptLineNumber will be different. So when compiled the script won't work as expected. The only way to fix such an error is to rewrite the code using methods that will work when you compile the script.

[TheSaint]

Sometimes, you just implement a manual switch in an ini file, to get the program to do error logging, which if it doesn't find, it doesn't do normally.

I've even on occasion, implemented Screenshots, at key moments, to help detect things the eye misses ... especially when working with third party programs.

[Melba23]

michaelslamet,

water suggested you search the forum - let me save you the trouble as adding the text below is a single keypress.

When compiling your script, run Obfuscator using the /STRIPONLY parameter. That way the compiler uses an au3 file which has the include files included, but all unused functions, variables, comments and blank lines removed. It is saved in the same folder as the source and named YourScriptName_Obfuscated.au3. You need to add these directives to the top of your script:

#AutoIt3Wrapper_Run_Obfuscator=y
#Obfuscator_Parameters=/so

Then when the error occurs, it is easy to see which line gave the fault as it is this Obfuscated file which has been compiled - just scroll to the indicated location. The only problem we know of is that using the line continuation operator screws up the count, but apart from that it works fine.

Of course, you need the full SciTE4AutoIt3 package, which you can download from here if you do not already use it.

M23

[silver217]

add another 1000+ lines to your script:  (I would use excel to do that)

trace('1')

..

trace('2')

...

etc.....

Func trace($x)

$tracefile = fileopen(c:mytracefile.txt',1)

FileWriteline($tracefile,$x)

fileclose($tracefile)

EndFunc

 

enjoy,

[water]

Or use function _FileWriteLog. It automatically adds date and time to the log entries.

[Mat]

Write a small script that reads each line and replaces @scriptlinenumber with the actual line number.

Won't work with the @scriptlinenumber default value for a parameter trick.

[water]

  On 6/22/2013 at 6:58 AM, michaelslamet said:

@water and czardas: yes, I will But nobody know's what will happen in the future, let say when the PC upgrade the OS or upgrade the service pack or anything else

That is why you usually test a script in different environments (operating system, versions of other applications the scripts automates (Office, Broser ...) etc.).

Then you add this information to the Readme file so the user knows what to expect from your script. When a new OS is released and the script crashes then the user wouldn't be surprised.

[water]

  On 6/22/2013 at 7:21 AM, michaelslamet said:

It only throw an error when run as compiled and never when run from SciTe

Can you please tell us which error messages you receive? Do they change or is it always the same?