Opened 15 years ago

Closed 15 years ago

#646 closed Bug (Fixed)

Call statement -- setting of @error

Reported by: pdaughe Owned by: Valik
Milestone: Component: AutoIt
Version: Severity: None
Keywords: Call, @error Cc:


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)

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.

Attachments (0)

Change History (7)

comment:1 in reply to: ↑ description Changed 15 years ago by 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:

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.

comment:2 Changed 15 years ago by Rob Saunders <therks@…>

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

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

comment:3 Changed 15 years ago by Jpm

  • Resolution set to Fixed
  • Status changed from new to closed

doc updatre as @error can be returned now.

comment:4 Changed 15 years ago by Jpm

  • Component changed from AutoIt to Documentation

comment:5 Changed 15 years ago by TicketCleanup

  • Milestone set to Future Release

Automatic ticket cleanup.

comment:6 Changed 15 years ago by Valik

  • Component changed from Documentation to AutoIt
  • Milestone Future Release deleted
  • Resolution Fixed deleted
  • Status changed from closed to reopened

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:

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

comment:7 Changed 15 years ago by Valik

  • Milestone set to
  • Owner set to Valik
  • Resolution set to Fixed
  • Status changed from reopened to closed

Fixed in version:

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

as closed The owner will remain Valik.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.