Difference between = and ==

[czardas]

Returning zero as an error value has both advantages and disadvantages. The disadvantage is that zero is quite often a valid return value and parameter: so error checking with nested functions can become problematic. I have experimented (once or twice) with setting infinity as the error return value. I believe it is likely to be effective in all situations, but I don't know. Doing this may also cause AutoIt to crash in some circumstances. It needs some study.

Oh and by the way: trancexx is very helpful and there's no point in beating around the bush. As she pointed out: if anyone can reproduce the error written in a clear way then she will look at it. That's got to be easy enough to understand.

Edited August 9, 2012 by czardas

[BrewManNH]

Usually if the return on an error is 0, the @error is the value you should be looking at, that way if there's an error you'll know it, and if the return of zero is a valid return, then @error will also be zero (usually).

[czardas]

Usually if the return on an error is 0, the @error is the value you should be looking at, that way if there's an error you'll know it, and if the return of zero is a valid return, then @error will also be zero (usually).

This is of no merit if you are using nested functions though.

[BrewManNH]

This is of no merit if you are using nested functions though.

I'm not following.

[MvGulik]

I think czardas is talking about a case where @error is not used, but the normal function return date is used for both returning data and a possible error case/data. (yes?)

---

O yea: Initial though on topic: 60 reply's ... wtf is going on there. ... Doh (no other comment on that part)

Edited August 9, 2012 by MvGulik

[czardas]

I mean Func3 passes the return on zero to Func2 which in turn passes on the return value to Func1. Error checking requires the nested functions be separated, otherwise it can't be guaranteed reliable.

Return Func1(Func2(Func3(0)))

Edited August 9, 2012 by czardas

[BrewManNH]

That return would be essentially useless unless each function returns a value based on what is received from the inner functions, and if it's returning the values, there is no reason it can't return an error value.

• Func3 returns value 4, Func2 receives 4, and then returns that to Func1, Func1 returns the value 4 to the Return statement, @error = 0.
• Func3 returns value 0 @error set to 1, Func2 receives that 0 and the error and returns that to Func1, Func1 returns 0 and the error and returns that in the Return.
• Func3 returns 0 @error = 0 (valid for func3), Func2 expects 3, returns 0 and @error = 1, Func1 expects 1, gets zero, checks @error, sees error, returns 1 and @error to Return statement.

Just some ways that you should be writing your functions to return valid values based on what it's doing and if 0 can be a valid return value, then make sure your SetError command takes that into account.

[czardas]

The point is that any error thrown in an earlier function is automatically overridden on the next function call. So long as zero is a valid parameter, the error will not be passed on. I never specified the final return, nor the type of functions. The usefulness of the functions is not really relevant. The point is about the return value zero having drawbacks. How serious they are depends on your perspective. The return value infinity throws a cascade of consecutive errors and may be more suitable if you are nesting functions, so long as it doesn't crash the interpreter..

Edited August 9, 2012 by czardas

[BrewManNH]

I'd have to disagree with that statement.

If 0 is a valid return, and you know that 0 can be a valid return value, then there is no error being returned and the @error returned from the 3rd inner function should be 0. If one of the inner functions is returning a value in @error, it doesn't matter if the returned value is 0 or "banana", your 2nd function should indicate to its calling function that it received an error, and if it doesn't then the function isn't written very well.

[czardas]

It's more a question of if 0 is a valid parameter. It's not a question of whether it is a valid return value. One or more of the functions may not have any valid numeric return values at all. You can't stop people from writing bad cade using your functions, whatever error return value you set. They will do it time and time again. So what is a good error return value? Is it zero, an empty string or what? You can certainly guarantee that people will nest functions inside each other regardless of usefulness.

Edited August 9, 2012 by czardas

[BrewManNH]

@error set to anything other than 0 is the best assurance you'll have that the function encountered an error. Some of the UDF functions return -1, some return 0, some don't tell you what the return value is if it's not 1, they just say @error set. Other than documenting what the error returns are and why, there's not much you can do to avoid stupidity.

[czardas]

Well I use nested functions such a lot. I have not had time to investigate it properly. So far 1/0 has proved to be a reliable error return value since no function I have ever come across will accept infinity as a parameter. It has also not caused AutoIt to crash, but I wasn't actually trying to crash the interpreter at the time. Perhaps if I tried hard enough to do that by this method, I would succeed: in which case I'd also have to report it as a bug.

Edited August 9, 2012 by czardas

[BrewManNH]

How exactly do you enter infinity as a value?

[czardas]

You don't need to, just use Return SetError(1, 0, 1/0) That get's passed on to the next function which automatically fails, which is exactly what you want to happen.

oops bad syntax (quite a funny) oversight, which I just fixed!

It's not standard proceedure, as far as I know tho!

Edited August 9, 2012 by czardas

[Mechaflash]

_1()
msgbox(0,"",@error) ; @error = 99

Func _1()
    _2()
    Return SetError(@error)
EndFunc

Func _2()
    _3()
    Return SetError(@error)
EndFunc

Func _3()
    Return SetError(99)
EndFunc

[czardas]

It's very a good idea, but not many people write code like that. I often see things like Return Number($string) Sometimes you see: $string = Number($string) followed by an error check. (no you don't)

Actually that was a bad example. How about this instead => For $i = 0 To Random($var) Perhaps that is plain bad code, but it looks normal to me.

Edited August 9, 2012 by czardas

[BrewManNH]

I'm definitely having a "being dense" day,

I get what you're saying in the nested example above, if the return value of Func3 is 0, then that is seen as Func2(0) in Func2 and the error returned isn't passed on to Func2. I don't write function calls like that myself normally, but I can see it being a valid point if you do it that way. Unfortunately, there's no consistency in the included UDFs that come with AutoIt, so the only way to be sure is to know what the returned values should be and shouldn't be and write your code accordingly.

[czardas]

Unfortunately, there's no consistency in the included UDFs that come with AutoIt, so the only way to be sure is to know what the returned values should be and shouldn't be and write your code accordingly.

I absolutely agree.

Edited August 9, 2012 by czardas

[bogQ]

trying to pass lowest error in tree line to top func error? i don't see any good point of doing that, your limiting errors to be enumerated, if not your not gonna know what func returned with error and even if you do everyone will get confused. i dont see any point in structuring code like that especially if you have a lot of funcs involved.

Edit: topic is off the track (especially cos it's solved), chat forum should be better at this point.

Edited August 9, 2012 by bogQ

[MvGulik]

Not advisable, but you can have reliable @error code passing in a "A(B(C()))" function set. (for other topic some other day I guess.)