ErrorLevel

Discuss the future of the AutoHotkey language
User avatar
jeeswg
Posts: 4786
Joined: 19 Dec 2016, 01:58
Location: UK

Re: ErrorLevel

29 May 2018, 11:40

- @Helgef: Generally speaking you can use the function return value, and scrap ErrorLevel. However, not in all cases, sometimes ErrorLevel needs a replacement.
- Looking through my scripts just now, ErrorLevel is useful if the function fails for some reason, maybe people prefer all this try/catch/exception stuff. I'd rather let the function silently fail, and check ErrorLevel. This is the simplest/shortest solution.
- However, I would want ErrorLevel to be used only to check *errors*. This is not the case with InputBox or Sort. So the simplest solution here would be to create two new A_ variables. This would also make modifying scripts easier: replace ErrorLevel with the appropriate A_ variable. Also, the use of ErrorLevel for InputBox clutters my scripts (about half of the occurrences of ErrorLevel, for a non-error), another reason for a separate A_ variable.
- In my custom functions, the return value usually tells you all you need to know. I might have been using ErrorLevel more widely in my custom functions up till now, but I've been waiting to hear how AHK v2 will handle errors.
User avatar
nnnik
Posts: 3067
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: ErrorLevel

29 May 2018, 11:52

- @Helgef: Generally speaking you can use the function return value, and scrap ErrorLevel. However, not in all cases, sometimes ErrorLevel needs a replacement.
I have defined a rule which completely covers all cases for replacing ErrorLevel.

All other Errorthrowing methods other than throw need to die too. There is just not aother viable option when working on advanced scripts.
Recommends AHK Studio
Helgef
Posts: 3096
Joined: 17 Jul 2016, 01:02
Contact:

Re: ErrorLevel

29 May 2018, 12:00

I'd rather let the function silently fail, and check ErrorLevel

You should stick to v1 then.
User avatar
jeeswg
Posts: 4786
Joined: 19 Dec 2016, 01:58
Location: UK

Re: ErrorLevel

29 May 2018, 12:03

- @nnnik/@Helgef: There's a difference between 'advanced' and verbose.
- Simplicity, brevity, functionality. I try to do everything in the most efficient and lean way possible, but never cutting corners.
- If you have 4 5-line blocks just to handle errors in an otherwise 5-line function, it starts to get pretty unwieldy.
Helgef
Posts: 3096
Joined: 17 Jul 2016, 01:02
Contact:

Re: ErrorLevel

29 May 2018, 12:13

If you do not handle errors, you are cutting corners.
User avatar
nnnik
Posts: 3067
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: ErrorLevel

29 May 2018, 12:20

Programming is a task where you are always cutting corners because programming is essentially a task similar to measuring the length of the border of a country.
When you talk about simplicity you simply say that you are cutting more corners then others.

And impementing a throw does not take longer than implementing the setting of an ErrorLevel.
Adding Try/Catch for any kind of error does outweight the debugging it takes to find that error.
Just recently you didn't find an error in DllCall after ErrorLevel had been set because you didn't bother to check it.
Recommends AHK Studio
swagfag
Posts: 944
Joined: 11 Jan 2017, 17:59

Re: ErrorLevel

29 May 2018, 13:18

I'd rather let the function silently fail, and check ErrorLevel.

why would you want something to fail and remain unaware of it?
User avatar
jeeswg
Posts: 4786
Joined: 19 Dec 2016, 01:58
Location: UK

Re: ErrorLevel

29 May 2018, 13:25

- @swagfag: If a function failed, if this failure would impact my script, I'd use ErrorLevel or the return value to take appropriate action.
- I'm concerned with some people's approaches to error handling, that absolutely *anything*, including the most minor thing, could terminate my script unexpectedly. And that potentially error handling is becoming too verbose, bloating scripts for no actual improvement in error handling.
- Maybe there are already solutions in place. I need more clarity. But even recently the error handling for numbers has been changed. Can I set a mode at the start of the function to suspend such error messages, and check for a blank string indicating a calculation error. I.e. the AHK v1 approach is pretty good generally speaking.

- @nnnik:
offtopic
Last edited by jeeswg on 29 May 2018, 14:04, edited 2 times in total.
User avatar
nnnik
Posts: 3067
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: ErrorLevel

29 May 2018, 13:59

You dont seem to understand what the notion "Throwing an Error" means. It essentially means that something went wrong inside your script and that your script is not working anyways.
- If a function failed, if this failure would impact my script, I'd use ErrorLevel or the return value to take appropriate action.

You would use Try Catch to appropriately address this error. In the new version - not much difference.

- I'm concerned with some people's approaches to error handling, that absolutely *anything*, including the most minor thing, could terminate my script unexpectedly. And that potentially error handling is becoming too verbose, bloating scripts for no actual improvement in error handling.
I am not concerned. I know that idiotic approaches will always fail - just like this one.
An actual Error already affects your script in some way. Noticing this and finding the source with the ErrorLevel method is more work than just writing Try Catch after being notified by the script of an error and fixing it accordingly.
Small code has no value other than being easy to understand. Easy to understand code thats hard to write and incorrect is useless. We dont need simplicity. We need ease of use and completeness.

mode
Modes like this need to die a permanent death too.
Recommends AHK Studio
User avatar
jeeswg
Posts: 4786
Joined: 19 Dec 2016, 01:58
Location: UK

Re: ErrorLevel

29 May 2018, 14:10

- You exaggerate the complications involving errors. I check the return value and/or ErrorLevel, and act appropriately. If blank/error then action.
- This is an odd use of language: 'something went wrong inside your script', usually what happens is that something that I know could fail, fails, and so I need to handle that situation, e.g. FileMove. You seem to have problems with possible bugs in your scripts, and needing to handle those. I basically never have this kind of problem, and safety checks throughout my scripts should prevent this being a problem. One of the reasons you get so many random errors is because of some of the OOP paradigms that you use that lead to more bugs on average than other OOP/non-OOP paradigms.
User avatar
nnnik
Posts: 3067
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: ErrorLevel

29 May 2018, 14:36

You are the prime example of a frog in the well.
Recommends AHK Studio
SirRFI
Posts: 404
Joined: 25 Nov 2015, 16:52

Re: ErrorLevel

29 May 2018, 15:11

@jeeswg Think of the example I provided: I wasted at least half an hour before figured out ErrorLevel was returning 2, as initially I based on function's true/false result. I thought image cannot be found for some reason and went all over the place rechecking everything. It could be avoided if the function threw Exception that there's an error. I can only guess how often someone experiences a problem like this.

If you know there's a chance of error appearing (such as file doesn't exist), you have to handle it either way, no matter if you prefer using ErrorLevel or getting an Exception on your face. The difference is error will let you know about it straight away it happens (and possibly provide more information than just a number), including places you didn't expect error to happen, while otherwise (errorlevel) fails silently and further code that may be dependant on this action will behave differently, causing you to manually debug that part first.
Use [code=autohotkey] forum tag to share your code.
Click on (Accept this answer) on top-right part of the post if it has answered your question / solved your problem.
User avatar
jeeswg
Posts: 4786
Joined: 19 Dec 2016, 01:58
Location: UK

Re: ErrorLevel

29 May 2018, 15:22

- @SirRFI: The AHK v1 ImageSearch command is very awkward for a number of reasons. The ImageSearch function should be more straightforward. Did you experience the problem in AHK v1 or v2? In theory, you could turn an error mode on or off, people have asked for a no error message mode. Checking ErrorLevel should have revealed the problem, right? (Btw I had considered that ImageSearch could return a blank string if an error occurred.)
- I tend to write scripts to meet the strictest requirements, so I guess my scripts will end up meeting the most exacting error handling standards. If I go along with this, I'm not sure yet whether error-handling script bloat could be avoided.
- Maybe people could do a demo script for what they think standard error handling should look like. To make a useful contribution to the thread.

- [EDIT:] So many things to think about. I think one of the best approaches would be this: the error messages come up, but you set it so that they don't terminate the script. That way everybody wins. In the worst-case scenario you get another script to repeatedly read the error messages, to verify whether to proceed.
- (This will be particularly useful during the AHK v1 to v2 transition, as I will likely get new error messages that I never got before. But would rather avoid losing all of my data each time a minor error occurs.)
- The question is then, some way to prevent accidentally clicking Yes/No on an error message, which is a problem even if you do want the script to always terminate.

offtopic
User avatar
nnnik
Posts: 3067
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: ErrorLevel

29 May 2018, 17:14

I cannot teach you the entirety of all my OOP knowledge as it took me 3 years to learn it and I'm still not quite there yet.
OOP is far from a simple topic but it's pretty standardized. If you do want to learn it I reccomend learning it by yourself.
I think that most other people that actually know OOP understand what I'm saying and agree with me.
Recommends AHK Studio
just me
Posts: 5431
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: ErrorLevel

30 May 2018, 03:46

  • Flipeador wrote:This is the reason why 0 should be Success... ;)
    NT_SUCCESS(Status):
    Evaluates to TRUE if the return value specified by Status is a success type (0 − 0x3FFFFFFF) or an informational type (0x40000000 − 0x7FFFFFFF).
    SUCCEEDED macro:
    This macro is defined as follows:

    Code: [Select all] [Download] GeSHi © Codebox Plus

    #define SUCCEEDED(hr) (((HRESULT)(hr)) >= 0)

  • 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.
    An object returned by a function always evaluates to True!

    Code: [Select all] [Download] GeSHi © Codebox Plus

    If FunctionReturningAnObject() { ; always true
    ...
    }

  • Are we talking about built-in functions which still may be called like 'commands'? What's so bad with ErrorLevel, the name?
Last edited by just me on 30 May 2018, 03:53, edited 1 time in total.
User avatar
nnnik
Posts: 3067
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: ErrorLevel

30 May 2018, 03:48

just me 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.
An object returned by a function always evaluates to True!

Code: [Select all] [Download] GeSHi © Codebox Plus

If FunctionReturningAnObject() { ; always true
...
}
Yes but why is this relevant information and what do you mean to tell us by this?
Are we talking about built-in functions which still may be called like 'commands'?
I was talking about the replacement of ErrorLevel and output variables for v2 and making them return values instead.
Recommends AHK Studio
just me
Posts: 5431
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: ErrorLevel

30 May 2018, 03:55

How would a check for success of a function call look like, then?
User avatar
nnnik
Posts: 3067
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: ErrorLevel

30 May 2018, 04:34

What do you mean by that?
If a function encountered an error it will throw an error.
If a function finished normally without encountering an error the result will be a return value.
All possible return values can be encoded.
How exactly that looks like depends on the function.
e. g. if the ImageSearch function should also return the position of an found image it will return an object on success which contains them (In this case an array would be fine too).
If it fails to fiund the image it would return an empty string.
However this differs from function to function and depends on whats to be encoded.
Recommends AHK Studio
just me
Posts: 5431
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: ErrorLevel

30 May 2018, 04:47

nnnik wrote:e. g. if the ImageSearch function should also return the position of an found image it will return an object on success which contains them (In this case an array would be fine too).
If it fails to fiund the image it would return an empty string.
And the additional information available in ErrorLevel until now will get lost? I don't see any advantage over

Code: [Select all] [Download] GeSHi © Codebox Plus

If !ImageSearch(OutputVarX, OutputVarY, X1, Y1, X2, Y2, ImageFile) {
If (ErrorLevel = 2) ; we know that ErrorLevel has been set
...
Else If ...
...
...
}
User avatar
nnnik
Posts: 3067
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: ErrorLevel

30 May 2018, 05:09

The main advantage is that the return value of ImageSearch can be stored inside arrays and objects immediately - just in case you did not know yet you cannot store inside an object using byRef.
The other advantage is that with throw even newbies will be aware of errors. You immediately safe the second if.
Throw will also remind you of rare errors that you do not know of yet.
Simply put with Throw you dont need to learn where to look for errors before debugging making development a lot easier for newbies while almost making no noteable difference towards more advanced developers.
The argument for making the output an object is consistency. You can do that and replace the large amount of random output vars we have and achieve more cosistency than with output vars.
We also avoid the often needless cluttering of variable scope that happens due to ByRef vars.
Recommends AHK Studio

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 2 guests