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?

[TAC109]

@lexikos
Thanks for your reply. I can see now that my request above is impractical.

Since you're already parsing some directives, you could parse #Warn directives and divert only the warnings which are enabled.

Although Ahk2Exe parses the source script plus #Includes for the purposes of creating the combined script in RcData, it runs the original source through the appropriate interpreter to detect errors etc. This allows an error message to refer to the correct source file and line number concerned. Thus it is difficult to divert any #Warn directives directly.

A possible future concept would be for Ahk2Exe to instead RunWait something like the following script through the v2 interpreter to detect errors and warnings:

Code: Select all

#Include 'path\to\original-script'
#Warn all, StdOut
#Warn LocalSameAsGlobal, off

(These '#Warn's would be changed to reflect any #Warns encountered in the parsed script.) StdOut would be directed to the same file as used for StdErr. After the RunWait, Ahk2Exe can detect that warnings occurred if the exit code is 0 and the StdOut file contains data. Can you see any pitfalls with this approach? Would it work with the Module enhancements?

I would prefer to have the same code work for v2.0 and v2.1 so would not want to use any /Warn switch unless it was back-ported to v2.0. Ditto for the recent #Warn enhancements in v2.1.

Cheers

[lexikos]

Using #Warn as above only affects the last module. In future, the scope of #Module might end at the end of the file which contains it, in which case the above would affect only the default module. If #Warn isn't used by the script, using it up front would set defaults which are inherited by all modules defined by #Module, but not separate modules imported from file.

A module which wants to play nice should leave the mode unspecified (to use the default mode). #Warn StdOut at the bottom of the script applies to all warnings which don't specify a mode, in all modules.

Fixed ExitApp on load-time error/warning dialogs to use exit code 2.
Source: v2.0.16

If you are using /ErrorStdOut, you can check stdout to distinguish between load-time errors and the user clicking ExitApp on a warning dialog.

The experimental dll can validate a script in-process and be notified of errors and warnings, but it is far from having a stable API. This capabilities might at some point be present in a standard install, either via dll or out-of-process COM server.

DBGp provides a means of redirecting both StdOut and OutputDebug (MsgBox warnings are also sent to OutputDebug), but currently /Debug makes a connection only after loading the script.