Page 1 of 1

Mute returns from functions - should we avoid them?

Posted: 15 Sep 2019, 16:24
by john_c
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?

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

Posted: 15 Sep 2019, 16:46
by BitcoinVirus
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!

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

Posted: 15 Sep 2019, 17:45
by jeeswg
- (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.

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

Posted: 15 Sep 2019, 19:03
by john_c
@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".

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

Posted: 27 Sep 2019, 22:34
by john_c
@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.

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

Posted: 29 Sep 2019, 10:45
by jeeswg
- 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
}

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

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

Posted: 30 Sep 2019, 02:27
by john_c
Thanks, it answers my question.