ExitCode Topic is solved

[pneumatic]

I'm trying to use ExitCode to control how my script exits.

Is this how ExitCode is intended to be used, or are there scenarios where ahk posts its own unpredictable ExitCode, say for example if ahk encounters some runtime error and wants to quit?

In other words, is ExitCode completely under my control?

Code: Select all

OnExit("ExitApp")
ExitApp , 2 
return

ExitApp(ExitReason, ExitCode){

	If (ExitCode = 0){ 
		MyFunction0()
		ExitApp
	}
	If (ExitCode = 1){ 
		MyFunction1()
		ExitApp	
	}	
	If (ExitCode = 2){    ;this will execute 
		MyFunction2()
		ExitApp	
	}	
}

[SALZKARTOFFEEEL]

Any pre-execution error (such as a syntax error) causes the executable to exit with an exit code other than 0, typically 2, and OnExit is not called. There is nothing the script itself can do against this, it would require a ‘loader’.
Also, in the rare event that the executable crashes, OnExit is not called, and thus, your code doesn't run.
Of course, other OnExit functions can also tamper with this, or quit the script before your function gets run.

In general, though, I don't see why this code you provided is at all useful. Why not call the functions directly? The script is exiting itself just to call functions, so why not call the functions directly and then exit (without registering OnExit)?

Finally, I'd like to say that naming a function ExitApp is bad practice. It is a reserved word and cannot, for example, be used as a variable name, so it should also not be used as a function name.

[swagfag]

In general, though, I don't see why this code you provided is at all useful. Why not call the functions directly? The script is exiting itself just to call functions, so why not call the functions directly and then exit (without registering OnExit)?

it useful because it avoids duplication if ure going to ExitApp from more places with the same exit code

Finally, I'd like to say that naming a function ExitApp is bad practice. It is a reserved word and cannot, for example, be used as a variable name, so it should also not be used as a function name.

its not a reserved keyword.
it can be used as a variable.
whether its bad practice or not, whatever

[SALZKARTOFFEEEL]

In general, though, I don't see why this code you provided is at all useful. Why not call the functions directly? The script is exiting itself just to call functions, so why not call the functions directly and then exit (without registering OnExit)?

it useful because it avoids duplication if ure going to ExitApp from more places with the same exit code

Not sure what you mean. Instead of registering an OnExit function that calls another function and then exits anyway, and then exiting the script to call that function, you can always just call it directly.
Instead of code A, you could always do code B:

Code: Select all

; code A
OnExit("ExitFunc")
ExitApp x

ExitFunc() {
  msgbox going to exit
  ExitApp
}

Code: Select all

; code B
ExitFunc()
ExitApp

The only difference is that ExitApp will terminate instantly when already in the OnExit-thread, which is why it should not be present in an OnExit function.

Finally, I'd like to say that naming a function ExitApp is bad practice. It is a reserved word and cannot, for example, be used as a variable name, so it should also not be used as a function name.

its not a reserved keyword.
it can be used as a variable.
whether its bad practice or not, whatever

Ah, sorry, I was thinking of v2 here. v2 has more reasonable naming rules, disallowing control-flow-words to be used as names.

[swagfag]

Code: Select all

global CANT_OPEN_FILE_ERROR := 42

if cantopenfile1
	ExitApp CANT_OPEN_FILE_ERROR

SomeOtherFunc() {
	if cantopenfile2
		ExitApp CANT_OPEN_FILE_ERROR
}

class SomeClass
{
	__New() {
		if cantopenfile3
			ExitApp CANT_OPEN_FILE_ERROR
	}
}

MyOnExitFunc(reason, code) {
	if (code = CANT_OPEN_FILE_ERROR)
	{
		LogIt("ps: yes, thats right. i dont care about other onexit handlers")
		ExitApp
	}
}

[SALZKARTOFFEEEL]

Code: Select all

global CANT_OPEN_FILE_ERROR := 42

if cantopenfile1
	error(CANT_OPEN_FILE_ERROR)

SomeOtherFunc() {
	if cantopenfile2
		error(CANT_OPEN_FILE_ERROR)
}

class SomeClass
{
	__New() {
		if cantopenfile3
			error(CANT_OPEN_FILE_ERROR)
	}
}

error(code) {
	if (code = CANT_OPEN_FILE_ERROR)
	{
		LogIt("hmmm")
		ExitApp
	}
}

In this case, of course, you could also just use exceptions.

[swagfag]

i could also do many other things as well, none of which have any bearing on or detract from OnExit's code param usefulness

[pneumatic]

Thanks guys.

Funnily enough, the original topic of this thread was going to be asking about what is the purpose of OnExit when you can just make your own function and call that instead

According to docs, here are some things unique about the OnExit routine

-does not obey #MaxThreads and cannot be interrupted by any thread, including hotkeys, custom menu items, and timed subroutines
-if OnExit thread encounters failure condition such as runtime error, script will terminate. This prevents a flawed OnExit callback function or subroutine from making a script impossible to terminate.
-if another script uses RunWait on it, ExitCode can be passed to that script via its ErrorLevel should work regardless, but docs don't explicitly say
-ExitReason is automatically provided by ahk
-Reload automatically triggers OnExit