Return code after error condition

[kanumi]

After an error condition, that is not handled by the script itself, e.g. a syntax error, the return code currently remains 0.

How would it be possible to have a different RC in this condition.

My preferred solution would be, to enable a script to change the default RC of 0 to a different value (aka SetError()).

The script can than change the value during successful proceeding.

[this-is-me]

There is currently a way to trap errors:

http://www.autoitscript.com/forum/index.php?showtopic=6535

[kanumi]

There is currently a way to trap errors:

http://www.autoitscript.com/forum/index.php?showtopic=6535

<{POST_SNAPBACK}>

That's just what lead me to this suggestion.

:"> tempacc1 was me without access to my login data

It would be really easier and safer for a process running a child process to just examine the RC than to scan or regexp the stdout-stream.

Is there a real reason why a process on error has to return 0?

[this-is-me]

No, but the fact is that a script can return any value it wants. Try this in an compiled code and see what I mean:

Exit(-5000542)

Your %errorlevel% will read -5000542

That means that there can be no set standard for allowing autoit to return a bad value, because the script could also return that same value.

[kanumi]

No, but the fact is that a script can return any value it wants. Try this in an compiled code and see what I mean:

Exit(-5000542)

<{POST_SNAPBACK}>

Yes, that's just why i suggested setting the default RC by the script itself.

And having a default RC different from 0, on an error condition that terminates the script, would be good.

It's just a case of a definition. If You know for e.g. on error RC equals 9999, if You did not change the default, than you can avoid Your script returning 9999 itself.

So my suggestion put together:

On an error found by the AutoIt-interpreter that terminates the script An RC different from 0, that is well documented .

A possibility like "SetExitCode(value)" to let the script overwrite the default.

That means that there can be no set standard for allowing autoit to return a bad value, because the script could also return that same value.

<{POST_SNAPBACK}>

As i see it, currently we have the ambiguity with returning 0.

It's a old habbit returning 0 for 'i did it all well'

I know about C++ compiled code that even overwrite the RC within termination code, if the dynamic allocated data isn't freed completely.