To what extent should commands be expected to throw on wrong type of inputs?

[safetycar]

I just accidentally passed an object to WinText instead of WinTitle, and there wasn't any error.
I've noticed after that some other commands not throwing when passed objects when they are defined in the docs to only expect strings.
Is this expected?

[swagfag]

either the documentation is wrong or the implementation is wrong

i see no quoted documentation nor any code posted, so what do u want us to do with this thread?

[safetycar]

I didn't have a clear idea if it was wrong or not, so I also didn't know exactly what I wanted myself. I guess I was waiting to see where the conversation lead.

But I could have posted more details.

Here some things that I tried after the first problem:

Code: Select all

WinWait("", {}) ; wrong WinText parameter type but no error
Gui({}) ; wrong Options parameter type but no error

The original problem itself is quite weird because it started with a bit of an experimentation thing.
It started with ControlClick but I've tried to reduce it and I'm just finding that this thing gives a result that makes sense for some reason...

Code: Select all

WinA := WinExist("A")
MsgBox WinA "`n`n" WinExist("", {hwnd:WinA}) ; both lines same hwnd

But I'm misusing things so I didn't quite want to make reference to any of this.

[swagfag]

both the documentation and the implementation are wrong. the documentation in the sense that its incomplete, the implementation in the sense that it doesnt complain ure passing garbage values in

in the case of WinWait()(as well as all other WinText, Timeout, ExcludeTitle, ExcludeText]-type functions) all try extracting a string from the optional arguments if possible or use an empty string if not possible, instead of validating the arguments to begin with:
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script2.cpp#L1050-L1052
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script2.cpp#L1093-L1094
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script_func_impl.h#L54-L55
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script_func_impl.h#L44-L48
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script_func_impl.h#L2
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script2.cpp#L16989-L16991

in the case of WinExist():
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script2.cpp#L14019

in the case of Gui() constructor
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script_gui.cpp#L504

---

in the case of

Code: Select all

WinA := WinExist("A")
MsgBox WinA "`n`n" WinExist("", {hwnd:WinA}) ; both lines same hwnd

knowing what u know now(that any objects u pass in, but shouldnt have, get converted to empty strings) u can explain away why the hwnds are identical:

• WinExist("A") returns the hwnd of the active window and sets the LastFoundWindow to it
• WinExist("", {hwnd:WinA}) which then becomes WinExist("", "") which returns the hwnd of the LastFoundWindow
• both hwnds are the same

[safetycar]

Thanks for the detailed explanation. Although I get a general idea I'll be trying to understand it a bit better later.

Relating to the topic I'll wait some days to see if Lexikos says anything here or else I'll try to post a reminder in the bug reports section.

[lexikos]

To what extent should commands be expected to throw on wrong type of inputs?

To the extent that is documented. If the documentation does not specify any behaviour for a given input, you should withhold any expectations.

Validating the type of each parameter currently requires redundant code in each function. In future the functions might be defined with strongly-typed parameters and exposed to script by generating code from metadata (function signatures). In that case, parameter types can be validated as part of the process of conversion, consistently for all functions, and without code duplication.

However, There is no guarantee that WinWait( , obj) will throw even then. Maybe it will call obj.ToString(). This is not yet done for similar reasons to the above.

the implementation [is wrong] in the sense that it doesnt complain ure passing garbage values

ValueError: This argument is incorrect.

The caller is wrong to pass garbage values. Although detecting many errors is easy, it is generally impossible to anticipate and detect all errors. There should be no expectation that "garbage values" will be rejected by the function. Garbage can even sometimes coincide with a valid parameter value.

[safetycar]

@ Lexikos, Ok, thanks. I had a bit of an intuition about it that's why I didn't post it straightly as a bug. But still wanted to check, also as a way of suggestion if not possible currently.

[swagfag]

However, There is no guarantee that WinWait( , obj) will throw even then. Maybe it will call obj.ToString(). This is not yet done for similar reasons to the above.

the implementation [is wrong] in the sense that it doesnt complain ure passing garbage values

ValueError: This argument is incorrect.

after reading this i thought i had overlooked something and that ahk did throw an exception(specifically this one), so i went back to check... and it didnt. now im dying laughing over here. good one

well, the documentation does state that the expected parameter type is "String". it does not say that it would throw if an invalid parameter had been passed in, so if we go along with the "dont have any expectations that things that werent documented would happen" mantra, the documented expected parameter type should be changed to "Whatever you'd like, really"

but i understand v2 is a WIP, so we can let this slide