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.
ErrorLevel
ErrorLevel
Use
Code: Select all
[/c] forum tag to share your code.
Click on [b]✔[/b] ([b][i]Accept this answer[/i][/b]) on top-right part of the post if it has answered your question / solved your problem.
Re: ErrorLevel
This is the reason why 0 should be Success...
Re: ErrorLevel
What is "the" reason? 0 equals false, so if (ImageSearch... wouldn't work.
Use
Code: Select all
[/c] forum tag to share your code.
Click on [b]✔[/b] ([b][i]Accept this answer[/i][/b]) on top-right part of the post if it has answered your question / solved your problem.
Re: ErrorLevel
Treat 0 as success and any other value as an error, as do many WINAPI functions. This would solve your problem.
Re: ErrorLevel
I prefer 1 (true) to equal success.
Re: ErrorLevel
It is not about tastes or personal preferences, but about how useful and convenient it is.
Re: ErrorLevel
You say that there I a train why this specific behavior is useful but fail to provide it.
Recommends AHK Studio
Re: ErrorLevel
You can do:nnnik wrote:You say that there I a train why this specific behavior is useful but fail to provide it.
Code: Select all
If (ImageSearch(...))
MsgBox "Error: " . ErrorLevel
Else
MsgBox "OK!"
Re: ErrorLevel
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
If ( ImageSearch(...) ) ;if image search was successful
;vs.
If ( !ImageSearch(...) ) ;if image search was unsuccessful
Recommends AHK Studio
Re: ErrorLevel
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?
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
just me: I don't understand your logic.
Re: ErrorLevel
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.
Cheers.
Re: ErrorLevel
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:
For now just throwing "ImageSearch failed" should be fine.
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
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.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).
For now just throwing "ImageSearch failed" should be fine.
Recommends AHK Studio
Re: ErrorLevel
Yes I agree nnnik
Re: ErrorLevel
- 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.)
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.)
Last edited by jeeswg on 29 May 2018, 10:59, edited 5 times in total.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
Re: ErrorLevel
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.
Additionally variables that are implicitly set need to die a permanent death.
Recommends AHK Studio
Re: ErrorLevel
[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.
No. They differ in whether they return an error code (where 0 stands for 'no error') or a BOOL (where True stand for success).jeeswg wrote:@Flipeador: API functions differ in whether non-zero/zero are true/false.
Re: ErrorLevel
- @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.
- @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.
Last edited by jeeswg on 29 May 2018, 11:33, edited 4 times in total.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
Re: ErrorLevel
Truthnnnik 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.
Re: ErrorLevel
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.
Truthkczx3 wrote:Truthnnnik 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.
Return to “AutoHotkey Development”
Who is online
Users browsing this forum: thqby and 32 guests