SetError() Possible Bug

[flyingboz]

Posting here per the bug report guidelines before opening a possible bug report.

Per the docs, SetError now supports two additonal optional params, @extended and return value. Hooray!

However, the return value appears to have no effect. In my tests (3.2.0.1 and 3.2.1.12) the returned value is always zero.

Obviously, I can add a return line to the function and return a result, without destroying @error and @extended,

but the entire purpose of overloading SetError to support returning a value from a function is so that one doesn't have to do that.

Sample code to reproduce :

$c = 0 
While 1
    $c +=1
    $result = ce()
                ConsoleWrite (StringFormat('%s\t%s\t%s\n',$result, @error,@extended))
    If $c = 100 Then Exit
    WEnd
    
    Func ce()
        SetError(Random(0,9,1),Random(0,99,1),Random(0,999,1))
    EndFunc

[Valik]

Uhhh, hello? You still have to return the value. All specifying a return value for SetError() does is change what SetError() itself returns. It's not magically breaking the language rules and altering what the UDF will return. You still have to use the Return keyword to actually get that value out of the function:

$c = 0
While 1
    $c +=1
    $result = ce()
    ConsoleWrite (StringFormat('%s\t%s\t%s\n',$result, @error,@extended))
    If $c = 100 Then Exit
WEnd

Func ce()
    Return SetError(Random(0,9,1),Random(0,99,1),Random(0,999,1))
EndFunc

Edited December 15, 2006 by Valik
Clarity

[flyingboz]

Valik, thanks for your succint reply.

I would suggest that the docs be clarified to read:

Return Value

By default, none, however if the optional return value argument is passed, then SetError() will return that value.

Not thinking that there was a possible use for SetError to return a value, I had hoped that the parser had gotten smart enough to save me a line of code everywhere I wanted to return from a function with a defined return value. That, IMO, would be a useful line saver. One could then write one line of code instead of four everywhere one wanted to return from a function.

if $error_condition then SetError($foo,$bar,$blah)

;instead of:

if $error_condition then 
  SetError($foo,$bar)
  Return $blah
Endif

WRT 'breaking language rules' I would argue that the language rules could be adapted to handle it. We now have one line if statements, the sole purpose of which is reducing the number of lines the programmer has to type. As the parser is smart enough to tell the programmer whether or not the code is currently executing a UDF or not, it would be a relatively simple matter to implement the function as I (in error) thought it had been.

[Valik]

I won't do it and I will bitch and bitch until Jon pulls it back out if somebody ever does try to put it in. I am happy with this solution. I hated writing code like you show. Now I write:

If $error_condition Then Return SetError($foo, $bar, $blah)

The only thing you have to do is add the Return keyword. This keeps the feature well within the current rules of the language. It doesn't do any subtle tricks or behind the scenes shenanigans. It does what you want with the only thing being you must explicitly tell it to do so by using the Return keyword. So instead of doing a lot of work to make AutoIt smart enough to save you a line, AutoIt has the capability to save you a line if you are smart enough to use it.

And that is what the documentation says. It mentions that it changes SetError()'s return value, not the return value in general.

[flyingboz]

I won't do it and ...RANT...

Excellent alternative syntax. Thank you for the suggestion.

And that is what the documentation says. It mentions that it changes SetError()'s return value, not the return value in general.

You will note I did not say that the documentation was incorrect. I stated that it could be clarified. Particularly when the Remarks section also use the term 'function' to refer to a function other than SetError(). While the documentation here is perfectly clear to you, it was not to me. If you have a <LONG> history of programming in languages that do not allow you to perform such feats as your alternative one line rendition, the meaning is not nearly as clear.

And Valik, thank you for your contributions to au3, acerbic as your comments may be.