Load time warnings not captured by /ErrorStdOut

[TAC109]

@lexikos
Version 2 has the additional facility to report warnings at load time as well as errors. Unfortunately these warnings are not captured by the switch /ErrorStdOut, and in this case the exit code is zero. This means that if a script generates warnings Ahk2Exe is unaware of this fact and cannot capture the warning information.

I would like the v2 interpreter be modified in this respect to process load time warnings similar to the way errors are processed so that they can be captured by Ahk2Exe. The exit code could be the same (2) or different if you believe Ahk2Exe should handle warnings in a distinct way. This would also affect the documentation for the /Validate and /ilib switches, and #ErrorStdOut.

Cheers

[TAC109]

@lexikos
Any thoughts on this? As it stands at present any load-time warnings will be carried forward into the compiled .exe so that whenever this is run, the warnings will appear. It would be better if Ahk2Exe was able to trap load-time warnings and allow the user to continue the compile or abandon the run. Perhaps an exit code of 3 to distinguish this from an error (2).

Cheers

[lexikos]

Warnings can be trapped by adding #Warn x, StdOut. Since you're already parsing some directives, you could parse #Warn directives and divert only the warnings which are enabled.

Note: ErrorStdOut uses stderr for "legacy" reasons, but #Warn uses stdout.

Warning dialogs can also be detected fairly easily, with the only caveat being that one might be missed if the user dismisses it quickly enough.

If an error dialog is shown at load-time, the exit code is 2 for Abort (because it allows the program entry point to return 2) and 0 for ExitApp in current versions (because it terminates the program immediately as if the Exit menu option was used). Most tools probably use ErrorStdOut anyway, but for those that don't, an exit code of 2 would be more useful, and consistent with the documentation for /validate.

If a warning dialog is shown, the exit code is 0 for Continue and 0 for ExitApp in current versions. Perhaps it would be reasonable to treat the warning as an error when the user has chosen to abort by clicking ExitApp.

If a warning was sent to stdout, there is nothing to suggest that it should be interpreted as an error. Whether or not a non-zero exit code can be allowed when there were no errors, there is no need for it anyway since you can read the warning from stdout.

It probably doesn't make a lot of sense for the method of reporting warnings to be decided by #Warn when the interpreter is invoked with /validate /ErrorStdOut. Given the low impact and nature of the tools that use this combination of switches, maybe the documentation and behaviour can be adjusted to be more in line with the intended use of /validate, without considering it a breaking change.

However, suppose that someone has used #Warn via preprocessing or /include to send warnings to stdout, and I change /validate /ErrorStdOut to send warnings to stderr, consistent with errors. Maybe they're treating stderr and stdout the same, or maybe not, and I've broken their tool.

On the other hand, if /validate /ErrorStdOut causes warnings to be sent to stdout, we'd have new behaviour that is already undesirable (warnings inconsistent with errors). If it only affected warnings which are set to MsgBox output, you'd have warnings sometimes sent to stderr and sometimes stdout, depending on the script. If warnings were sent to both stderr and stdout, and MsgBox was ignored, there could still be issues with tools that expect only errors to go to stderr.

As a new feature, /Warn (or some other command-line switch) would be in v2.1, not v2.0.x. Would you wait for that, or work around it?