[JASS] Using uninitialized hashtable entries

[Antares]

Hello,

quick question. I want to put a cooldown on damage taken from a source by flipping a boolean in a hashtable at parentKey source and childKey target from false to true to store that the cooldown is active. The code surrounding it would look like this:

	function Reset takes nothing returns nothing
		//Do stuff.
		call RemoveSavedBoolean( particleTable , whichParticle , playerNumber )
	endfunction

	function Damage takes nothing returns nothing
		if not LoadBoolean( particleTable , whichParticle , playerNumber ) then
			//Do damage stuff.
			call SaveBoolean( particleTable , whichParticle , playerNumber , true )
		endif
	endfunction

The important point is that I never actually save "false" at position (whichParticle , playerNumber). In good old JASS-fashion, you would expect that the thread crashes on the first line in Damage, but it doesn't and it returns false. This is actually great because it saves me spamming the hashtable with a lot of entries. So, my question is, is there any downside to doing it like this? Can you use hashtable entries in which nothing was written yet as false, 0, and/or null without any problems?

 

[Uncle]

That's fine as far as I know, Booleans/Integers/Reals/Strings cannot be null and will always have a default starting value of False/0/0.00/"".

I've done this a few times and never noticed any issues so I doubt it's something to worry about.

 

[Antares]

That's fine as far as I know, Booleans/Integers/Reals/Strings cannot be null and will always have a default starting value of False/0/0.00/"".

I've done this a few times and never noticed any issues so I doubt it's something to worry about.

Thanks, then I will not worry about it! But if I recall correctly, you can even load handles from the hashtable and if there's nothing saved it will return null instead of crash, so I don't think it's because it's one of the types you listed.

 

[Pyrogasm]

Hashtable read functions always return default values for uninitialized entries. This is expected behavior for all variable types.

 

[Antares]

Why can't more functions work like this? Imagine GetExpiredTimer() not crashing your game when you call the timer callback function directly :|.

 

[Pyrogasm]

Because it's a database and in any context an uninitialized entry crashing your DB read is beyond stupid.

 

[Dr Super Good]

Back when hashtables were added you had to check the existence of a mapping. In your case you could use this test to check the value of the boolean since by it not being set it is false and by it existing it is true. Setting it to false would be done by removing the mapping rather than updating it to have a false value.

In the various patches since then I think they added enough sanity/safety checks that reading values from a not initialised mapping does not crash wc3 and instead returns a reasonable default value.