Page 1 of 3
ErrorLevel
Posted: 28 May 2018, 16:15
by SirRFI
I've used ImageSearch recently, which got me confused: functions now return something, and this particular one returns 0 on not found and 1 on match, which is opposite to ErrorLevel values. However, error is still shown only in ErrorLevel as 2.
Question is: do we still need ErrorLevel in such places, if at all? I like how the function returns true/false, allowing to put it in if or other place. Perhaps errors could throw exception instead? If anything, users could probably use try/catch to prevent exception from stopping code flow if needed. This would surely save me time where I put file path first, then options, which is seemingly not allowed.
Re: ErrorLevel
Posted: 28 May 2018, 16:41
by Flipeador
This is the reason why 0 should be
Success...
Re: ErrorLevel
Posted: 28 May 2018, 17:04
by SirRFI
What is "the" reason? 0 equals false, so if (ImageSearch... wouldn't work.
Re: ErrorLevel
Posted: 28 May 2018, 17:47
by Flipeador
Treat 0 as success and any other value as an error, as do many WINAPI functions. This would solve your problem.
Re: ErrorLevel
Posted: 28 May 2018, 18:59
by kczx3
I prefer 1 (true) to equal success.
Re: ErrorLevel
Posted: 28 May 2018, 19:40
by Flipeador
It is not about tastes or personal preferences, but about how useful and convenient it is.
Re: ErrorLevel
Posted: 28 May 2018, 23:53
by nnnik
You say that there I a train why this specific behavior is useful but fail to provide it.
Re: ErrorLevel
Posted: 29 May 2018, 00:32
by Flipeador
nnnik wrote:You say that there I a train why this specific behavior is useful but fail to provide it.
You can do:
Code: Select all
If (ImageSearch(...))
MsgBox "Error: " . ErrorLevel
Else
MsgBox "OK!"
Btw: I think you made a typo in your comment.
Re: ErrorLevel
Posted: 29 May 2018, 02:08
by nnnik
Yeah but you could do the same with the other way around. In fact it makes more sense the other way around:
If ( ImageSearch(...) ) ;if image search was successful
;vs.
If ( !ImageSearch(...) ) ;if image search was unsuccessful
Re: ErrorLevel
Posted: 29 May 2018, 04:59
by just me
Some API functions return an 'error status'. They commonly return 0 (= no error) on success, otherwise one of various possible error codes.
Other API functions return a BOOL. They commonly return a non-zero value on success, otherwise 0.
If a function returns either 0 or 1, it obviously belongs to the latter kind of functions. So why should it return 0 on success?
Re: ErrorLevel
Posted: 29 May 2018, 05:21
by Flipeador
just me: I don't understand your logic.
Re: ErrorLevel
Posted: 29 May 2018, 09:29
by Helgef
I can not see any reason for errorlevel existing in v2. Imagesearch return value isn't documented as far as I can see, it should probably return what errorlevel is set to now, and ofc, errorlevel shouldn't be set.
Cheers.
Re: ErrorLevel
Posted: 29 May 2018, 10:00
by nnnik
Nah ErrorLeve now is used for 2 things: return values and errors.
In AHK v2 it should only return the return value part of the ErrorLevel never the error part.
Thats what throw is used for.
e.g. ImageSearch is the perfect example of a command where you shouldn't:
Helgef wrote:probably return what errorlevel is set to now
ErrorLevel is set to 0 if the image was found in the specified region, 1 if it was not found, or 2 if there was a problem that prevented the command from conducting the search (such as failure to open the image file or a badly formatted option).
Only the 0 and 1 are part of the return value. The 2 is an error type and over the long run should result in descriptive error messages.
For now just throwing "ImageSearch failed" should be fine.
Re: ErrorLevel
Posted: 29 May 2018, 10:02
by Helgef
Yes I agree nnnik
Re: ErrorLevel
Posted: 29 May 2018, 10:42
by jeeswg
- If you remove ErrorLevel you have to account for all the things here:
ErrorLevel
https://autohotkey.com/docs/misc/ErrorLevel.htm
- Take InputBox for example, InputBox's return value is the text of the Edit field. But how are you supposed to know if the InputBox was closed? Furthermore it's not an 'error' if the user closes the InputBox. I thought of A_InputBoxResult as a possible answer.
- What about DllCall and Sort?
- @Flipeador: API functions differ in whether non-zero/zero mean success/failure. AHK needs to pick one, there isn't really a decisive answer either way.
- 0 or blank on failure, otherwise a meaningful result, is one approach. 0 or blank on success, otherwise a useful error code, is another approach.
- However, true=non-zero, and false=zero is pretty much universal (unless someone else knows better). And
if Func() is more intuitive if functions return non-zero to mean success. (Also, AHK functions have generally used the rule: non-zero: success, zero/blank: failure.)
Re: ErrorLevel
Posted: 29 May 2018, 10:44
by nnnik
Return values are to be returned by the function. If they are too complex for a single variable or a single string make the return value an object.
Additionally variables that are implicitly set need to die a permanent death.
Re: ErrorLevel
Posted: 29 May 2018, 10:58
by just me
[b]v2-changes[/b] wrote:
The translation from v1-command to function is generally as follows (but some functions have been changed, as documented further below):
- If the command's first parameter is an output variable and the second parameter is not, it becomes the return value and is removed from the parameter list. Otherwise, RunWait returns the exit code, and any other commands which set ErrorLevel return non-zero on success and zero on failure (except for SendMessage). Most legacy functions still set ErrorLevel.
jeeswg wrote:@Flipeador: API functions differ in whether non-zero/zero are true/false.
No. They differ in whether they return an error code (where 0 stands for 'no error') or a BOOL (where True stand for success).
Re: ErrorLevel
Posted: 29 May 2018, 11:00
by jeeswg
- @just me: I was just editing that bit. 'API functions differ in whether non-zero/zero are success/failure'.
- @nnnik: The Winapi functions GetLastError/SetLastError use what is effectively an implicit variable.
- The solution is either another parameter or another A_ variable (perhaps the best) or use ErrorLevel as now (or some other solution I haven't thought of, perhaps similar to or using OnError). If you return an object, it makes the InputBox function somewhat unwieldy to use, breaks scripts, it makes it inconsistent with other functions, and aesthetically the object solution would be dire. Aesthetics matter.
Re: ErrorLevel
Posted: 29 May 2018, 11:10
by kczx3
nnnik wrote:Return values are to be returned by the function. If they are too complex for a single variable or a single string make the return value an object.
Additionally variables that are implicitly set need to die a permanent death.
Truth
Re: ErrorLevel
Posted: 29 May 2018, 11:32
by Helgef
jeeswg, do you set errorlevel in your own functions? I guess you manage just fine without it. So does everybody else and ahk will too.
kczx3 wrote:nnnik wrote:Return values are to be returned by the function. If they are too complex for a single variable or a single string make the return value an object.
Additionally variables that are implicitly set need to die a permanent death.
Truth
Truth