Better error msg for (undefined) Global var in Function definition.

[mvg]

More informative error message for undefined vars(global) use in function parameter part.
Like using the func-def line-number and full function definition part.

#AutoIt3Wrapper_run_au3check=n
Function()
;; Global $NA='NA' ;; missing, or late global var definition.
Func Function($1=$NA)
	ConsoleWrite('$1=' & $1 & @CRLF)
EndFunc
;; Error out messages.
;; X:\...\MyAutoIt.au3 (2) : ==> Variable used without being declared.:
;; Function()
;; Function()^ ERROR

If you know/remember how to interpreted this error message, this message might be clear. But if you don't ... It might more than needed time to figure out the reported problem.

_(3.3.6.1)

[mvg]

It might take some, more than needed, time to figure out the reported problem.

[Valik]

It tells you there is an error on line 2. From there you should be able to figure out on your own to at least look at the function definition on line X.

Quite simply, this is not worth the time and risk associated with changing the behavior. Won't you feel real daft if we fix this error message but totally break something else that was otherwise working correctly?

This is also very simple to avoid. Global variables should always appear near the top of a script either before or after all #include statements but before any code is ever executed.

[mvg]

Replying to Valik:

It tells you there is an error on line 2. From there you should be able to figure out on your own to at least look at the function definition on line X.

You mean Autoit is not made as a kind of easy low level skilled code language.

Quite simply, this is not worth the time and risk associated with changing the behavior. Won't you feel real daft if we fix this error message but totally break something else that was otherwise working correctly?

I did not know you where the timid kind when it comes to code. Nor do I see why I would need to feel daft for someone else his failure for adding error free code. Is that not why you have preliminary beta version's. To flush out major problems like that.

Anyway, where talking about a error message here. How is some code that is only going to be called when a terminal error is detected going to break something else in a significant way.
Its not like I suggested a rewrite of the error detection or something like that. If thats whats needed to be able to change this particular (ambigues in my view) error message. Just say so.

This is also very simple to avoid. Global variables should always appear near the top of a script either before or after all #include statements but before any code is ever executed.

Yea, yea. And when you use #OnAutoItStartRegister I figure your not suppose to call functions that use any global variables.

#AutoIt3Wrapper_run_au3check=n
Global $G1 = 'G1'
Global $G2 = 'G2'
;~ Global $NA2 = 'NA2'
Func f1($1=$G1)
EndFunc
Func f2($1=$NA2)
EndFunc
Global $r1 = f1('f1') & f2('f2')
Global $r2 = f1() & $G2 & f2()
;; X:\...\MyAutoIt.au3 (9) : ==> Variable used without being declared.:
;; Global $r2 = f1() & $G2 & f2()
;; Global $r2 ^ ERROR

Yep, It clearly is showing in which function definition to look for the problem.

Or:
I think the Error message in these cases is ambiguous. And could use some improvement to make them less ambiguous and a lot more useful than there currently are. And considering AutoIt target audience I think its not such a stupid request as you like me to believe it is.

[Valik]

Replying to mvg:

Replying to Valik:

It tells you there is an error on line 2. From there you should be able to figure out on your own to at least look at the function definition on line X.

You mean Autoit is not made as a kind of easy low level skilled code language.

Quite simply, this is not worth the time and risk associated with changing the behavior. Won't you feel real daft if we fix this error message but totally break something else that was otherwise working correctly?

I did not know you where the timid kind when it comes to code.

Timid? No, just smart enough to know not to fuck with something that's working if a change adds questionable benefit.

Nor do I see why I would need to feel daft for someone else his failure for adding error free code.

It's called the law of unintended consequences. Besides, I didn't say it would take an error in the code to break behavior, only that behavior could break.

Also, it occurs to me why should we care about your (and possibly others) inability to write error-free code when you clearly don't care about our (potential) inability to do so for a feature you (and only you) request?

Is that not why you have preliminary beta version's. To flush out major problems like that.

Every single release there's a face-palmingly obvious bug missed. Every time. When you start messing around in the parser and lexer those bugs range from face-palmingly obviously to rather obscure and annoying. Obscure and annoying, much like this problem.

Anyway, where talking about a error message here. How is some code that is only going to be called when a terminal error is detected going to break something else in a significant way.
Its not like I suggested a rewrite of the error detection or something like that. If thats whats needed to be able to change this particular (ambigues in my view) error message. Just say so.

Do you cut a man's chest open and poke around with his lungs just because he has a cough? No, you wait until you actually have a reason to go in there. The parser/lexer for AutoIt is the same way. If it doesn't need touched it doesn't get touched. This request does not fall into the "It needs touched" category. It's a rather obscure corner case that's unlikely to affect very many people.

Yep, It clearly is showing in which function definition to look for the problem.

I can write bad code to demonstrate any problem I want and exaggerate it too. That doesn't make doing so a useful endeavor.

I think the Error message in these cases is ambiguous. And could use some improvement to make them less ambiguous and a lot more useful than there currently are. And considering AutoIt target audience I think its not such a stupid request as you like me to believe it is.

You're full of contradictions. If the users are not as skilled as you imply then chances are they aren't going to be writing OnAutoItRegister stuff and if they use it at all it will be from 3rd party libraries which should already be written and tested properly by others. As for other conditions under which they can produce the problem, maybe they need to learn a little code structure. This bug would probably not affect me because I am unlikely to ever write code in such a fashion. If for some reason I did write such code then it would be trivial to fix because I write code iteratively so changes from my last working version to now are only a handful of lines making them easy to visually inspect. In other words, people need to learn a little bit about how to write and test code.

[mvg]

Replying to Valik:

You're full of contradictions.

Yep.

Recap:

• To much risk (core code) for to little (questionable) benefit.