ErrorLevel

Discuss the future of the AutoHotkey language
just me
Posts: 9425
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: ErrorLevel

30 May 2018, 05:49

  1. Honestly, I don't want to be forced to enclose even more 'built-in functions' with a Try block. An internally generated exception message might be convenient for a programmer while testing. But it's often useless for most end users in many cases.
  2. If AHK v2 will go this way, it also has to scrap commands.
  3. OOP might be a good (if you prefer: the best) approach for some (if you prefer: many) problems, but not for all. (As long as common processors cannot handle objects natively, it's just 'syntax sugar' or a replacement of programming knowledge by a compiler.)
  4. As far as I know, AHK v2 is still aimed at users with little programming experience. So KISS might be the better approach. OOP techniques should be an additional option for more advanced users and not the overall concept. Otherwise, AHK might lose most of the 'noobs'.
  5. This conceptual change will delay the release of v2 again. I don't want to experience the release of AHK 1.1.48.05.
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: ErrorLevel

30 May 2018, 06:07

1. See OnError. Also an if block is not a lot different than a Try block.
2. Might be a nice idea
3. Well returning an object in a function is not really OOP.
4. AHK is indeed aimed at users with little to no programming experience. But users with little to no programming experience can learn OOP so I dont understand your point
In fact in many schools they teach Java as first language and it goes well. As it is now AHK is also not aimed at users that want to become full-fledged developers and fails to keep them.
5. The conceptual change in throwing more errors is something thats already decided and Ive been actually working on implementing some more errors.
Recommends AHK Studio
just me
Posts: 9425
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: ErrorLevel

30 May 2018, 08:49

1. I don't think that OnError() is really useful when you have to handle the error. You most probably need a Catch block in this case.
2. It's mandatory! If Result := ImageSearch(X1, Y1, X2, Y2, ImageFile) will return an object containing the values currently retrieved by output variables, how could it be called using the 'command-like' style?
3. Yes, but objects form the basis of OOP. Why at all do you want to return an object, then?
4. Who will do the job of the teachers?
5. Nice to know! I'll lay back again until AHK v2 will be beta. If I'm still interested and motivated at that time, I'll look what kind of language it has become. So long!
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: ErrorLevel

30 May 2018, 10:20

1. The OnError note was in reply to your "Warnings don't make sense for end users". Yeah Try & Catch vs If & Else. There is not much difference between the 2.
2. What about functions like Msgbox?
3. To remove ByRef variables
4. One of the easiest languages to learn programmin is Python. It is easier than AHK by a large margin. And although it is easier to learn and to get into than AHK it also is better for advanced programmers.
In AHK it often seems like it is completely impossible to use OOP if you dont understand OOP. Well that just isn't true.
You can use libraries that offer OOP classes without even understanding how to write classes yourself. Just as much as you are able use functions before being able to write your own functions.
Recommends AHK Studio
SirRFI
Posts: 404
Joined: 25 Nov 2015, 16:52

Re: ErrorLevel

30 May 2018, 12:47

jeeswg wrote: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 used v2 and performed actions depending on returned boolean (true = image found). As said, it took a while before I checked ErrorLevel and realised options have to be before file path.
If the function returned blank string, it would still result in false when used within an if. Other than that, getting nothing would probably cause more confusion.
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.
An object returned by a function always evaluates to True!
Yes, because it's not empty. In case of such functions, they would always return object with key that help determine whether it was successful or not.
just me wrote:How would a check for success of a function call look like, then?
As an example, APIs seem to often follow something alonglines this:

Code: Select all

{
	"success": true,
	"data_or_something": {...}
}
So, all you have to do is to if (variable.success) CJ.


Let me provide an example why I think having thrown exception is better over silent-fail:
Say I have a function that to work properly necessarily needs X and Y arguments to be integers.

Code: Select all

myFunc(X, Y)
{
	ToolTip("It's me!", X, Y)
}
myFunc("a", 50.50) ; appears in top-left of currently active window, because provided coords are invalid

myFunc2(X, Y)
{
	if !(X is "integer")
		throw Exception("Invalid argument type: expected integer, got " type(X))
	else if !(Y is "integer")
		throw Exception("Invalid argument type: expected integer, got " type(Y))
	ToolTip("It's me!", X, Y)
}
myFunc2("b", 60.60) ; error is shown - what, where and why is wrong
First version (myFunc) executes, but ends up in unexpected behaviour. The second one informs you straight away you made a mistake passing a string and a float to the function. In contrast to the earlier, actual example (ImageSearch) - I could be informed right away that I messed up argument order.

Now, if you really dislike error pop-up that stops the script, or simply expect that in some scenario it may fail:

Code: Select all

myFunc2(X, Y)
{
	if !(X is "integer")
		throw Exception("Invalid argument type: expected integer, got " type(X))
	else if !(Y is "integer")
		throw Exception("Invalid argument type: expected integer, got " type(Y))
	ToolTip("It's me!", X, Y)
}

try
{
	myFunc2("b", 60.60)
	; some more code that depends on myFunc2 non-error result
	ToolTip("Uh oh, this works!") ; ...if you fix passed arguments above
}
catch error
{
	ToolTip("myFunc ended up with error, but worry not - I can handle this!`n" error.message) ; error.message, because Exception() makes an object, but as shown in docs - you can throw a simple string too!
	; some code that takes care of the problem - something you'd put in if (ErrorLevel = 2) anyway
}
MsgBox("We still rockin'!")
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.
Helgef
Posts: 4709
Joined: 17 Jul 2016, 01:02
Contact:

Re: ErrorLevel

30 May 2018, 13:52

just me wrote:I don't think that OnError() is really useful when you have to handle the error.
I do not know why this function was added to v1, there are no errors :lol:. It will be useful in v2 though, especially with closures.

SirRFI and nnnik, these things shouldn't need to be explained, well put though, both of you. :thumbup:
jeeswg wrote:- 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.
[...]
(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.)
:D

Cheers.
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: ErrorLevel

31 May 2018, 06:11

- @Helgef: I'm not sure what you wish to mean by splicing those two quotes together. As an example, I don't use 'local', but other people asked me to support it in my functions. Error handling could result in something similar.
- I had a plan that if I had an old script that I'd converted to AHK v2, and there was a new kind of error, e.g. a maths error, I would use hotkeys to block keyboard/mouse input to the error MsgBox, so as to not accidentally click Yes or No, and then invoke a click on Yes to 'Continue running the script?'.
- That way I could learn about the new errors and update my scripts, but not have my scripts crash unexpectedly, due to new error criteria, and so avoid losing data.
- CRUCIALLY it seems that AHK errors are generally/always of the 'The current thread will exit.' kind and not of the 'Continue running the script?' kind, scuppering these ideas.

- I think it's worth mentioning all of the issues relating to errors:
- 'The current thread will exit.' v. 'Continue running the script?'
- AHK v2 has stricter error handling.
- Not clicking Yes or No accidentally on a MsgBox. (And/or error messages with a SoundBeep and/or time delay so that you can't press the buttons immediately.)
- MsgBoxes getting hidden under other windows.
- Allowing calculations to return a blank string and silently fail versus crash the script.
- Allowing all errors to silently fail. An on/off mode. (Similar functionality to AHK v1.)
- Using 'if ErrorLevel'.
- OnError.
- try/catch/finally, throw, Exception.
- [EDIT:] ErrorLevel is currently used for situations that aren't strictly errors: e.g. InputBox and Sort (remove duplicates).
- Anything else?

- When exactly do you get the 'Continue running the script?' Yes/No options? Does OnError allow this?

- Here is an AHK v1 example, to display some nice 'if ErrorLevel' handling. It keeps the code clear and short.
- There's also a try/catch example, however it gets ugly quickly. The readability declines rapidly, especially when you add in multiple error handling code blocks in otherwise short functions. Can the try/catch example be simplified e.g. the vError variable eliminated?
- My suspicion is that I'll need to remove every instance of ErrorLevel in future, and move to try/catch, but I'm not sure whether try/catch blocks can be made sufficiently succinct.
- Otherwise, if available, a one-liner to suppress error messages within the scope of a function, and using ErrorLevel might be the best option. [EDIT: On/off within a *function*, versus on/off within a *thread*, because otherwise you need to add curly braces to turn the mode on/off before the function ends (before any return line), which clutters the function.]

Code: Select all

;q::
vPath1 := A_Desktop "\blank.txt" ;a file that already exists
vPath2 := A_Desktop "\blank?.txt" ;an invalid path
if !FileExist(vPath1)
	FileAppend,, % vPath1

;ErrorLevel
Loop, 2
{
	FileMove, % vPath1, % vPath%A_Index%
	if ErrorLevel
		MsgBox, % "FileMove error"
	else
		MsgBox, % "FileMove success"
}

;try/catch
Loop, 2
{
	vError := 0
	try FileMove, % vPath1, % vPath%A_Index%
	catch
	{
		vError := 1
		MsgBox, % "FileMove error"
	}
	if !vError
		MsgBox, % "FileMove success"
}
return
- Here are some AHK v2 tests:

Code: Select all

MsgBox("hello")

;ACC
;I couldn't think of any internal-to-AHK examples that give the 'Continue running the script?' prompt (instead of the 'The current thread will exit.' prompt)
;this error gives you the option of whether to terminate the script or not
;Error:  0x80070057 - The parameter is incorrect.
;Continue running the script?
oGui := GuiCreate(, "MyWinTitle")
oLV := oGui.Add("ListView", "r3", "LVH 1")
Loop 3
	oLV.Add("Select", A_Index)
oAcc := Acc_ObjectFromWindow(oLV.hWnd)
Loop oAcc.accChildCount
	vOutput .= oAcc.accName(A_Index) "`r`n"
MsgBox(vOutput)

;OBJECTS
;this error terminates the script, with no option to continue
;Error:  No object to invoke.
;The current thread will exit.
oArray := {}
;MsgBox(oArray.a.b)

;THROW
;this error terminates the script, with no option to continue
;Error:  Unhandled exception.
;throw 3

;%CAUSE% := ERROR [based on an example in the documentation for OnError]
;this error terminates the script, with no option to continue
;%cause% := error
;Error:  This dynamic variable is blank.  If this variable was not intended to be dynamic, remove the % symbols from it.
;The current thread will exit.

;FILEMOVE
;FileMove was allowed to fail silently in AHK v2 which surprised me,
;everything else I'd tested seemed to be regarded as a fatal error,
;but I would prefer an option to suppress error messages,
;and use ErrorLevel checks to ensure that scripts would run correctly
vPath1 := A_Desktop "\blank.txt"
vPath2 := A_Desktop "\blank?.txt" ;invalid path
Loop 2
{
	FileMove(vPath1, vPath%A_Index%)
	if ErrorLevel
		MsgBox("FileMove error")
	else
		MsgBox("FileMove success")
}

;MATHS
;this works:
vError := 0
vNum := "abc"
try (vNum + 0 = "")
catch
	MsgBox("not num"), vError := 1
;how can I know if I there was an error?
;do I need to add the vError variable?
;is there not: try, catch (to handle error), else (if no error)

;MATHS
;this error terminates the script, with no option to continue
;Error:  Type mismatch.
;The current thread will exit.
vNum := "abc"
if (vNum + 0 = "")
	MsgBox("not num")

Acc_Init()
{
	Static	h
	If Not	h
		h:=DllCall("LoadLibrary","Str","oleacc","Ptr")
}

Acc_ObjectFromWindow(hWnd, idObject := -4)
{
	Acc_Init()
	If	DllCall("oleacc\AccessibleObjectFromWindow", "Ptr", hWnd, "UInt", idObject&=0xFFFFFFFF, "Ptr", -VarSetCapacity(IID,16)+NumPut(idObject==0xFFFFFFF0?0x46000000000000C0:0x719B3800AA000C81,NumPut(idObject==0xFFFFFFF0?0x0000000000020400:0x11CF3C3D618736E0,IID,"Int64"),"Int64"), "Ptr*", pacc)=0
	Return	ComObject(9,pacc,1)
}
Last edited by jeeswg on 31 May 2018, 12:57, edited 1 time 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
SirRFI
Posts: 404
Joined: 25 Nov 2015, 16:52

Re: ErrorLevel

31 May 2018, 06:57

jeeswg wrote:

Code: Select all

;try/catch
Loop, 2
{
	vError := 0
	try FileMove, % vPath1, % vPath%A_Index%
	catch
	{
		vError := 1
		MsgBox, % "FileMove error"
	}
	if !vError
		MsgBox, % "FileMove success"
}
return
This is v2 section and we are discussion changes for it. Overhauling that for v1 could possibly partially break backwards-compatiblity.
Also, I have no idea what you need vError variable for. Code from try is executed until an error, then it moves to catch block. If code from try is finished without exceptions, catch is not executed at all. Additionally, optionally there's finally block.
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.
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: ErrorLevel

31 May 2018, 13:10

- The AHK v1 example demonstrates my preferred use of ErrorLevel(/an equivalent).
- I thought that it might fail in AHK v2, either now or in future, hence writing it in AHK v1.
- I haven't said anything about changing AHK v1.

- The point about try/catch is this: 'if ErrorLevel' allows me to take one action on success/one action on failure. AFAICS try/catch does not let you easily do the same.
- So *yes* the well-known concept of try/catch appears to have a fundamental disadvantage when compared with the straightforward 'if ErrorLevel' approach (unless someone can spot a fix).
- (Not everything that is 'standard' in IT is always smart or a universal perfect solution, e.g. C++ appears to have 99 different types of array.)
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: ErrorLevel

31 May 2018, 14:36

Yeah there is a fix.
swagfag already provided the info for a possible more straightforward way.
Recommends AHK Studio
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: ErrorLevel

31 May 2018, 14:45

@nnnik: Are you sure? The idea is to shorten the second of these examples, to possibly remove the vError variable:

Code: Select all

;ErrorLevel
	FileMove, % vPath1, % vPath2
	if ErrorLevel
		MsgBox, % "FileMove error"
	else
		MsgBox, % "FileMove success"

;try/catch
	vError := 0
	try FileMove, % vPath1, % vPath2
	catch
	{
		vError := 1
		MsgBox, % "FileMove error"
	}
	if !vError
		MsgBox, % "FileMove success"

;a hypothetical hybrid
;although the ErrorLevel example is still more readable,
;plus it has the advantage that you can store ErrorLevel and check it anywhere,
;whereas try/catch/finally dictates the order of the script,
;by necessitating that things be arranged consecutively
	try FileMove, % vPath1, % vPath2
	catch
		MsgBox, % "FileMove error"
	catchsuccess [something like this]
		MsgBox, % "FileMove success"
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: ErrorLevel

31 May 2018, 15:43

Code: Select all

Try {
    Throw "unsuccessful"
    Msgbox successful
} Catch
    Msgbox unsuccessful
Recommends AHK Studio
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: ErrorLevel

31 May 2018, 16:26

- Thanks nnnik, that's quite helpful.
- I now have a try/catch halfway house that tries to maintain the 'if ErrorLevel' advantages. (I had suspected that I would need some new approach by the time AHK v2 was finalised.)
- (One readability drawback is that the important line always has to be indented since the actions that occur on success must be included within the same block of code.)
- For me then, the question becomes whether try/catch is consistent across AHK v1/v2 or whether there are exceptions.
- Another issue is that things like this are raised as errors on script startup: try A_ComSpec := ComSpec, such 'try' lines, to me, are exactly why 'try' should exist, and help allow older scripts to be forwards compatible.
- A key issue to me is the question of whether an error is fatal, or can be ignored, that doesn't seem to be considered in the current infrastructure, I could add a vIsFatal variable to the MyOnError function for example.
- Also, I am concerned that when people use my functions, if I use 'throw' inside the function, for even the slightest error, that could cause their script to crash. However, if I somehow specified throw with a Yes/No option, this gives them some flexibility. It also forces other users to have to use try/catch with my functions, this may or may not be a good thing.
- Btw also, we potentially reach a situation where virtually every line in a script requires the word 'try' before it. Although the OnError function can help by allowing a 'Continue running the script?' MsgBox for all/some errors instead of forcing 'The current thread will exit.' for everything.

Code: Select all

;AHK v1.1
;q:: ;error handling example
vPath1 := A_ScriptFullPath ;a file that already exists
vPath2 := A_ScriptFullPath "?" ;an invalid path

Loop, 2
{
	try
	{
		FileMove, % vPath1, % vPath%A_Index%
		MsgBox, % "FileMove success"
	}
	catch
		MsgBox, % "FileMove error"
}

Loop, 2
{
	try
	{
		FileMove, % vPath1, % vPath%A_Index%
		MsgBox, % "FileMove success"
	}
	catch e
		MyOnError(e, "FileMove error")
}

MsgBox
return

;note: maybe FileReadLine in AHK v1 would be worth keeping e.g. if the script is big
;note: granular access to the last n executed lines (cf. ListLines) would also be useful
;note: since the script may have included other scripts, the lines logically above/below the problem code line, may not be from the same script file
MyOnError(e, vMsg:="Error.")
{
		FileRead, vText, % e.File
		vLineText := StrSplit(vText, "`n", "`r")[e.Line]
		vOutput := ;continuation section
		(Join`s"`n"`s
			vMsg "`n"
			"Message: " e.Message
			"What: " e.What
			"Extra: " e.Extra
			"File: " e.File
			"Line: " e.Line
			"LineText: " Trim(vLineText)
			"`n" "Continue running the script?"
		)
		MsgBox, 4, Error, % vOutput
		IfMsgBox, No
			ExitApp
}
Last edited by jeeswg on 31 May 2018, 17:01, edited 9 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
SirRFI
Posts: 404
Joined: 25 Nov 2015, 16:52

Re: ErrorLevel

31 May 2018, 16:27

nnik's latest code will display messages only in v1, because they weren't enclosed in quotes. Mentioning that just in case someone gets confused by empty MsgBox.


I prepared another example: say our script logic has to move the file first, then edit or append something to it, then it's ready to send somewhere. Any of these operations can fail - file to move might not exist, you or the script may have no proper rights to move or edit it, and lastly there may be no connection to send it somewhere. For demonstration purposes, the functions accepts true (success) or false (error). Change the passed argument to see how the script behaves, although fail in the middle should be good enough for explanation.

Code: Select all

try
{
	moveFile(true)
	editFile(false)
	sendFile(true)
}
catch var_to_store_error_message
{
	MsgBox("I tried really hard, but: " var_to_store_error_message)
}



moveFile(should_i_work)
{
	success := should_i_work
	if (!success)
		throw "I failed to move the file."
}
editFile(should_i_work)
{
	success := should_i_work
	if (!success)
		throw "I didn't manage to edit the file."
}
sendFile(should_i_work)
{
	success := should_i_work
	if (!success)
		throw "Couldn't send the file."
}
As you can see, there is no need for whole bunch of if-else with ErrorLevel, or use helper variables, even though one function relies on another.
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.
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: ErrorLevel

31 May 2018, 18:05

Yeah you need to rethink your approach to errors and error handling. Work load wise there isn't any difference between if/errorlevel and try/catch. However they are used in entirely diffent ways.
Recommends AHK Studio
User avatar
kczx3
Posts: 1640
Joined: 06 Oct 2015, 21:39

Re: ErrorLevel

31 May 2018, 21:00

I’m not sure how it all works in AHK, but try/catch in JavaScript causes a slight performance degradation (though likely not noticeable). Also, I don’t really like the idea of having to wrap all kinds of stuff in a try/catch.
Helgef
Posts: 4709
Joined: 17 Jul 2016, 01:02
Contact:

Re: ErrorLevel

01 Jun 2018, 03:34

@ jeeswg, exceptions doesn't crash the script, silent failure might very well do if error checking isn't adequate.

For those who are worried about wrapping everything in try/catch blocks, don't be, for most exceptions there is no need to handle it in any other way than correcting a code error, example,

Code: Select all

dllcall "MessageBox___", "ptr", 0, "str", "hello", "str", "world", "uint", 0x40
The above would silently fail in v1, in v2, you get notifed and fixes it, not further considerations. Try doens't make sense here, and no one uses errorlevel for that, hence, it is a pain to find the problem in v1.
Some problems needs to be handled, typical example,

Code: Select all

m := allocatePermanentMemory()
try {
	; use m
	;
} catch e {
	free(m)	; have to free m on any error above to not leak memory
	throw e
}
A likely scenario is that you use m above in a bunch of dllcalls, checking errorlevel after each dllcall, and take appropriate actions on error, is a mess. Try is superior. (edited)
jeeswg wrote:- AHK v2 has stricter error handling.
I'd say, it is just better, the experiment to allow the script to continue unconditionally on failiure, trusting that the user would check errorlevel, just didn't work out, we are on track again :thumbup:.

cheers.
lexikos
Posts: 9560
Joined: 30 Sep 2013, 04:07
Contact:

Re: ErrorLevel

01 Jun 2018, 20:09

Helgef wrote:I do not know why this function was added to v1, there are no errors :lol:
I do not know why you would say that. There are clearly "errors" in v1. You've seen error dialogs with the text "The current thread will exit". These are what OnError intercepts. The primary purpose of OnError is as I said:
It could be used to suppress the standard error dialog (by returning true) and optionally show a custom one, or perform additional error-handling such as writing to a log file.
Source: Test build - Obj.Count(), OnError(), long paths, experimental switch-case - AutoHotkey Community
See also suppressing run time error messages?
jeeswg wrote:When exactly do you get the 'Continue running the script?' Yes/No options?
Only COM errors give that option. ComObjError(false) suppresses these errors.
Does OnError allow this?
No.
SirRFI wrote:As said, it took a while before I checked ErrorLevel and realised options have to be before file path.
As a general rule, the built-in functions should throw an exception if given invalid parameters, since it indicates a defect in the script rather than a condition that the script should handle. (In such cases, exception handling is just the mechanism used to alert the author to the problem; the script is not expected to handle the exception.) Many commands in v1 already do this. I'll change ImageSearch in v2.
myFunc("a", 50.50) ; appears in top-left of currently active window, because provided coords are invalid
Numeric parameters (esp. for functions that were commands) are often not validated. One of my long term goals is to allow general validation of common parameter patterns (such as this) without increasing the code size proportionate to the number of parameters (i.e. without needing check-and-throw code for each parameter). Until then (or until each ex-command is refactored), they probably won't be validated.
SirRFI
Posts: 404
Joined: 25 Nov 2015, 16:52

Re: ErrorLevel

02 Jun 2018, 03:25

lexikos wrote:
SirRFI wrote:As said, it took a while before I checked ErrorLevel and realised options have to be before file path.
As a general rule, the built-in functions should throw an exception if given invalid parameters, since it indicates a defect in the script rather than a condition that the script should handle. (In such cases, exception handling is just the mechanism used to alert the author to the problem; the script is not expected to handle the exception.) Many commands in v1 already do this. I'll change ImageSearch in v2.
myFunc("a", 50.50) ; appears in top-left of currently active window, because provided coords are invalid
Numeric parameters (esp. for functions that were commands) are often not validated. One of my long term goals is to allow general validation of common parameter patterns (such as this) without increasing the code size proportionate to the number of parameters (i.e. without needing check-and-throw code for each parameter). Until then (or until each ex-command is refactored), they probably won't be validated.
I wrote that as an example of "unexpected behaviour" when there's silent error or no error handling, and why we should use throw instead of errorlevel in general. Nice to hear there will be input validation though.
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.
lexikos
Posts: 9560
Joined: 30 Sep 2013, 04:07
Contact:

Re: ErrorLevel

06 Jun 2020, 06:19

v2.0-a110 is of particular relevance to this topic.

Return to “AutoHotkey Development”

Who is online

Users browsing this forum: No registered users and 53 guests