How does AHK handle wrong function arguments?

[john_c]

Here are two tests.

Code: Select all

; The default value of the 3rd argument is False
; As the 3rd argument, I use "WrongArg"
; It seems "WrongArg" is treated as False
MsgBox % InStr("aaa_XY_bbb", "xy", "WrongArg")  ; => 5

Code: Select all

; The default value of the 6th argument is 1
; As the 6th argument, I use "WrongArg"
; It seems "WrongArg" is treated as 0, not 1
MsgBox % RegExReplace("123", "\d", "x",, -1, "WrongArg")  ; => 12x

It seems these tests show that AutoHotkey handles wrong (i.e, unexpected) arguments inconsistently. Isn't it?

[boiler]

It’s treating both as 0. What’s not consistent?

[john_c]

Hmm, you are correct, thanks. It seems I need a break.

[SKAN]

I'm answering the topic title.
 

Code: Select all

MsgBox % InStr("aaa_XY_bbb", "xy", "1WrongArg")  ; => 0

The above will work correctly in AHK v1
because the 3rd parameter requires a number, and is equivalent to Round("1WrongArg").

I faced a parsing problem in my FileSelectFile()
as FileSelectFile, OutputVar, m16@!#!@!$!!$ is valid and I wanted my function to be a mimic.

I use the following method to parse the number out:

Code: Select all

Options   :="m16@!#!@!$!!$"
FirstChar := SubStr(Options,1,1)
StartPos  := (FirstChar="m" || FirstChar="s") ? 2 : 1
MsgBox % Round( SubStr(Options, StartPos) )

 
Round() cannot be abused this way in AHK V2, but Format() seems to be working in V1 and V2.

Code: Select all

;MsgBox % Format("{1:d}", "1WrongArg")
MsgBox Format("{1:d}", "1WrongArg")

[lexikos]

Error: Parameter #3 invalid.

Line#
---> 001: MsgBox(InStr("aaa_XY_bbb", "xy", "1WrongArg"))

... is what you'd get with AutoHotkey v2.

InStr in AutoHotkey v1 (but not v2) expects an integer for the CaseSensitive parameter. It does not interpret the parameter directly as boolean. Otherwise, "WrongArg" would be considered true.

For parameters that must be numbers, AutoHotkey v1 interprets values according to the underlying C functions, such as atoi and strtoi. These functions attempt to convert the string to a number, stop processing at the first non-numeric character, and ignore the rest. If there are no numeric characters, the result is probably always 0.

FileSelectFile, OutputVar, m16@!#!@!$!!$ is valid

No; that is one of many cases where an invalid parameter value is not detected. (But I see no problem with wanting to replicate the behaviour.)

[john_c]

@lexikos, but what about the situations where a function expects a string?

Here is a comparison of how FileOpen() and HotString() work. If we use "WrongArg", the former function returns 0 instead of an object, but the latter throws an error.

Code: Select all

; If the 2nd argument is wrong, the function returns 0
MsgBox % FileOpen(A_ScriptFullPath, "WrongArg")             ; => 0
MsgBox % FileOpen(A_ScriptFullPath, "WrongArg").ReadLine()  ; => empty string

; If the 3rd argument is wrong, the function throws an error
Hotstring(":*:btw", "by the way", "WrongArg")

Just in case, correct versions:

Code: Select all

; https://www.autohotkey.com/docs/commands/FileOpen.htm
MsgBox % FileOpen(A_ScriptFullPath, "r")             ; => object
MsgBox % FileOpen(A_ScriptFullPath, "r").ReadLine()  ; => the 1st line of the file

; https://www.autohotkey.com/docs/commands/Hotstring.htm
Hotkey, IfWinActive, ahk_exe sublime_text.exe
Hotstring(":*:btw", "by the way")
Hotkey, IfWinActive, ahk_exe notepad.exe
Hotstring(":*:btw", "by the way", "Off")

[boiler]

You are just pointing out that they are both working exactly as documented.

FileOpen:

If the function fails, the return value is 0...

Hotstring:

This function throws an exception if the parameters are invalid...

[SKAN]

For parameters that must be numbers, AutoHotkey v1 interprets values according to the underlying C functions, such as atoi and strtoi. These functions attempt to convert the string to a number, stop processing at the first non-numeric character, and ignore the rest. If there are no numeric characters, the result is probably always 0.

Thanks for the useful info.

[john_c]

You are just pointing out that they are both working exactly as documented.

Yes, but why FileOpen() doesn't check whether its 2nd argument is a valid string (that is, either "r", "w", "a", "rw", "h", and some others) the same way as Hotstring() do?

[boiler]

Perhaps it’s because functions added by Lexikos (v1.1+) include parameter validity checking while older functions do not. I haven’t checked to see if that’s true in general.