Execute(error macro)

[RTFC]

Greetings y'all,

While tracing an issue flagged by user MagicSpark here:

I came across this puzzling AutoIt behaviour:

Seterror(1)
If @error Then Beep(1111,100) ; this works

Seterror(1)
If Execute('@error') Then Beep(1111,100) ; this fails

Now I'm not sure whether this should be considered a bug or a feature. I presume Execute starts by resetting @error (and @extended) and updates it with a non-zero error code when something fails along the way. Trouble is, this makes evaluation of @error's origiinal content within an Execute envelope impossible, thereby breaking my decryption (see my CodeCrypter thread). The example above is of course just for illustration, but in Codecrypter any line containing @error no longer works (always returns zero for successful Execute).

In the absence of "onError' or some form of previous-error logging facilities, would it be possible to preserve the state of @error and @extended (for example, through internal tempvars) inside the Execute handling itself just sufficiently long for actual evaluation to be possible?

I realise this is a bit of a chicken-and-egg situation, but before I code up an elaborate work-around in CodeCrypter, I'd like to check with you devs whether a simple fix would resolve this.

Thanks for looking into this,

RT

[jchd]

I don't consider this as a workaround, rather correct use of Execute:

Seterror(1)
If @error Then MsgBox(0, "", "If") ; this works

Seterror(1)
If Execute('@error = 0') Then MsgBox(0, "", "Execute") ; this works as well

[RTFC]

Thanks for your response, but you're testing the wrong condition. As I wrote, @error always comes back zero inside an Execute, whereas I'm testing non-zero. As far as I can tell, your example still fails, like this:

Seterror(1)
If @error Then Beep(1111,100)   ; this works

Seterror(1)
If Execute('@error=1') Then Beep(2222,100)  ; this fails

[jchd]

Oops, that's a good hint that I need some sleep. You're of course right on this point.

[czardas]

This might give you some ideas. The code is a bit ugly, but the concept is straight forward enough. I still haven't got around to using this method with the project I had originally intended, which also uses Execute BTW.

Edited February 21, 2014 by czardas

[RTFC]

Hi czardas,

That's a great collection of snippets you 've got there (hadn't seen these before). BTW love your music-related contributions to the forums!

I understand the idea you suggest, but I'm afraid in this particular case it won't solve the problem. The user is testing the contents of @error directly after calling some AutoIt function (or maybe setting @error directly with SetError(1), as in my little example). But since the code that evaluates the content of @error is wrapped inside an Execute envelope, it is reset to zero (by Execute itself) prior to its evaluation wthin the Execute execution (sounds confusing, doesn't it?). In the CodeCrypter thread I referred to in the original post, I suggested the workaround to insert an extra line of unencrypted code into the fully encrypted script afterwards that would capture the @error status in a regular $variable that can subsequently be evaluated at leisure (as it won't be wiped by an Execute call). But one would have to do this manually at all locations where @error is checked, and repeat all edits whenever one generates a new version of the encrypted script. So that's not an option.

As I understand it, the problem lies inside the Execute command itself, and the question boils down to whether @error's status as determined by executing the previous line can somehow be preserved just long enough inside the Execute command handler to enable evaluation of that status.

So instead of this:

1. some call sets @error nonzero
2. some statement with Execute('@error')
   a) reset @error, @extended
   b) check for errors, set @error if any test fails
   c) parse string to internal AutoIt command processor

I'd imagine something like this:

1. some call sets @error nonzero
2. some statement with Execute('@error')
   a) local $error=@error
   b) local $extended=@extended
   c) reset @error, @extended
   d) check for errors, set @error if any test fails
   e) replace @error with $error, @extended with $extended in the parameter string
   f) parse string to internal AutoIt command processor

Perhaps this would be easy to fix, or perhaps not; I can't tell.   But in the absence of 'OnError' constructs I cannot think of any way that this could be fixed at the script level. Any subsequent code the user produces to avoid this is itself also Execute-wrapped in CodeCrypter, so the reset still occurs before the original status can be captured.

[czardas]

I see. It is indeed complex. I have 50+ maths functions, either ones I modified or ones wrote myself, which (when tested) ought to nest and still support error handling; but there is no encryption involved. Modifying 50 functions is enough for my purposes, but if I had to do more then I would probably start to look for other solutions.

Thanks for your comments. The snippet dump has some rubbish in there too. I try to clean the thread up every now and again.

Edited February 21, 2014 by czardas

[Richard Robertson]

I'm pretty sure most of the AutoIt built in functions reset the error code when they start as boilerplate code.

[RTFC]

Hi Richard Robertson,

Yeah, that's what I feared. So my questions are,

1) given the special "meta" nature of the Execute command, and (as I understand it at least) that it is supposed to parse its argument as-is to AutoIt's internal command handler as an executable AutoIt phrase, does the fact that it itself alters the state of @error prior to parsing it constitute a bug in the way the Execute command handles @error?

2) if so, could this be easily patched in a future release? That is, does @error get reset by a generic preprocessor that then passes control to specific command handlers or does each command handler do this internally (so it would be easier to handle Execute's special case scenario)?

I guess only a core dev would be able to answer that...

I'd really like to know one way or the other, because if it cannot/won't be fixed then I'll have to design an elaborate work-around that I'd rather avoid for various reasons (not just being lazy).

Anyway, thanks for your input.

[Richard Robertson]

From the help file on the page "Function Notes"

@error is always set to 0 when entering in a function.

 

This is intended behavior and not a bug. It also appears that every built in function resets the error state.

[RTFC]

Much obliged, Richard, I missed that note completely.

In that case, I will write a work-around for CodeCrypter.

Thanks for clearing that up, I'll mark this thread as resolved.

RT