Call statement -- setting of @error

[pdaughe]

Following execution of the Call statement, @error may be set by the called function. Thus, @error does not indicate the called function does not exist. In previous AutoIt releases, @error was only set if the called function did not exist, as documented.

Call ("Test")
If @error Then MsgBox (0, "Test", "Error = " & @error)
Func Test ()
SetError (2)
EndFunc

I wasn't sure what to put under severity, but for me, this is a significant issue. A global variable can be used to retrieve the error code of the called function if necessary.

[Valik]

Replying to pdaughe:

In previous AutoIt releases,

Which release?

I wasn't sure what to put under severity, but for me, this is a significant issue.

Everybody's issue is always severe to them otherwise they wouldn't bother reporting it (for the most part). You did right in not setting it and it would be futile to set it anyway as there is a script that will unset it.

I'm not sure what's right here. I clearly did not think about or have no memory of my thoughts on called functions setting @error and @extended and whether or not that should be available after Call(). I'm not sure how I feel about that. On the one hand, Call() does need some way to indicate failure. On the other hand it makes sense that the @error and @extended values will propagate up just like the return value is returned. However, the other argument is, if you know the function you will use Call() on is going to set @error then chances are you know what function is going to be called in the first place and could presumably not use Call() altogether. But then the other side of that is, you may know from a finite list which function will be called and know that all of them obey the same conventions as far as setting @error.

What I'm trying to say is, I don't know what to do. The only thing I can think of is to set @error to an arbitrary number and @extended to an arbitrary number on failure so that you would do something like:

Call("function")
If @error = 9385 And @extended = 12042 Then MsgBox(0, "", "Call() failed.")

This would allow both Call() to report errors and the called function itself to report. The chances of the called function setting both @error and @extended to the magic (documented) values is low enough to be viable. It is certainly unprecedented but it does solve all the issues even if it has to do so in an inconsistent way.

[Rob Saunders <therks@…>]

Nah, just make new macros @callerror and @callextended. ;)

As if those wouldn't get misused near instantly...

[Jpm]

doc updatre as @error can be returned now.

[TicketCleanup]

Automatic ticket cleanup.

[Valik]

I'm re-opening this. Here's what I'm going to do. I'm going to modify Call() so that when it fails it sets @error to 0xDEAD and @extended to 0xBEEF. Call() needs to be able to signal it didn't find the function but the called function also needs to be able to set @error and @extended as well. So I'm going to have Call() set @error to a value that is unlikely to be used (or at least less commonly used than 1). Also @extended will be set as well. The likelihood of both @error and @extended being set by a called function to the values I mention above is very low. Code should be written like this to test for failure:

Call("function")
If @error = 0xDEAD And @extended = 0xBEEF Then ; Call() failed to find the function

[Valik]

Fixed in version: 3.2.13.10