Mute returns from functions - should we avoid them?

Get help with using AutoHotkey and its commands and hotkeys
john_c
Posts: 340
Joined: 05 May 2017, 13:19

Mute returns from functions - should we avoid them?

15 Sep 2019, 16:24

Are there any reasons to have functions like this one?

Code: Select all

Func(Var)
{
    If (Var = "Foo")
        Return
}
In real life, it can has a lot of code. The key point is that it has only one exit point, and this exit point is mute.

Here are another examples, to compare them with the first one:

Code: Select all

Func(Var)
{
    If (Var = "Foo")
        Return False
}

Code: Select all

Func(Var)
{
    If (Var = "Foo")
        Return "Error"
}
So, my question could be asked in another way:

Is it correct that we should avoid to use mute Returns when returning from functions, and use Return False, Return "Error" or something similar instead?
User avatar
BitcoinVirus
Posts: 15
Joined: 31 Jan 2019, 11:21

Re: Mute returns from functions - should we avoid them?

15 Sep 2019, 16:46

I don't see the reason to use return if you don't use the function to call a variable as the response, thus I see no reason to use a return without it returning anything.

Sorry for my poor English!
User avatar
jeeswg
Posts: 6904
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Mute returns from functions - should we avoid them?

15 Sep 2019, 17:45

- (These are just some general comments to summarise what I've seen, and not intended particularly as advice.)
- AFAICR, for me, functions are either 'doers' (often 'set' functions, setters) or 'returners' (often 'get' functions, getters).

- Typically a 'returner' will return a string/number/object, perhaps with a blank string (or possibly zero) indicating failure.

- Typically a 'doer' will return 0 for failure, or 1/non-zero for success. Sometimes it will do things the other way round: 0 for success, and non-zero for failure. Such results are common with Winapi functions.
- ... Sometimes I like to return a blank string for an error, thus giving: success/failure/error. (E.g. does a file exist? Yes/no/an error occurred when trying to find out.)
- Winapi functions often write a 'last error' value, obtainable via GetLastError and AHK's A_LastError variable.
- In AHK, functions can also output additional information by using ByRef parameters. (In addition, they can set the value of the ErrorLevel variable.)

- One key thing to consider is that in AHK, we do not have a 'null' value.
- So, for complete clarity in my functions, I now like to specify return "" and never return (which is equivalent) by itself. I.e. to indicate that a blank string is being returned, and not a null value.

- Btw, do you have any source for the term 'mute return'? Thanks.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
john_c
Posts: 340
Joined: 05 May 2017, 13:19

Re: Mute returns from functions - should we avoid them?

15 Sep 2019, 19:03

@jeeswg

> do you have any source for the term 'mute return'?

There is no source, I "created" this "term" myself. Another option would be "parameterless return".
john_c
Posts: 340
Joined: 05 May 2017, 13:19

Re: Mute returns from functions - should we avoid them?

27 Sep 2019, 22:34

@jeeswg

> - So, for complete clarity in my functions, I now like to specify return "" and never return (which is equivalent) by itself. I.e. to indicate that a blank string is being returned, and not a null value.

Could you provide some real life example? An example which is not from real life, but is created specifically for education purposes could be - probably - even better. Thanks.
User avatar
jeeswg
Posts: 6904
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Mute returns from functions - should we avoid them?

29 Sep 2019, 10:45

- I've tried to answer your question, do post more info if I haven't quite answered it.

- A function's return value is typically a numerical error(/success) code.
- But it can also be the value you want to return.
- E.g. ControlGetText could legitimately be a blank string, if the control is empty.
- FileGetAttrib returns the attributes for a file as letters, and this could legitimately be empty. (Note: FileExist does the same, but returns X for a file with no attributes, thus it always evaluates as true if a file exists.)
- To have both a return value and an error(/success) code, a function could return an error code via a ByRef function parameter, via ErrorLevel, or via SetLastError/A_LastError.

- One area of debate, is, when a function fails, whether to return a blank string, or whether to throw an error (which terminates the script, unless you use 'try'). I show some possibilities for error handling below.

Code: Select all

;q:: ;test error handling possibilities
vPath := A_ScriptFullPath
MsgBox, % MyFileGetSize(vPath)
MsgBox, % MyFileGetSizeAlt(vPath)

vPath := A_ScriptFullPath "x" ;non-existent file
MsgBox, % MyFileGetSize(vPath) ;if fail, return blank string and keep running script
try
	MsgBox, % MyFileGetSizeAlt(vPath) ;if fail, keep running script (and run catch block if it exists)
catch
	MsgBox, % "file not found:`r`n" vPath
MsgBox, % MyFileGetSizeAlt(vPath) ;if fail, terminate script
return

;==================================================

MyFileGetSize(vPath)
{
	local
	if !FileExist(vPath)
		return ""
	FileGetSize, vSize, % vPath
	return vSize
}

MyFileGetSizeAlt(vPath)
{
	local
	if !FileExist(vPath)
		throw Exception("file not found:`r`n" vPath, -1)
	FileGetSize, vSize, % vPath
	return vSize
}

;==================================================
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
john_c
Posts: 340
Joined: 05 May 2017, 13:19

Re: Mute returns from functions - should we avoid them?

30 Sep 2019, 02:27

Thanks, it answers my question.

Return to “Ask For Help”

Who is online

Users browsing this forum: AHKStudent, Google [Bot], holahapi, MannyKSoSo and 219 guests