When is it neccessary to nil check?

Help and Feedback Scripting Support
#1

So, I started writing some server functions that loads house data for players. First I get the name of their owned house from the data store (a string). Then, I go into to replicatedStorage, go to the Houses Folder and FindFirstChild(ownedHouse).

At this point is it neccesary to nil check if the ownedHouse model exists, or is that just added work on the server that’s not need? This is probably negligible amount of work, but if this is happening hundreds of time on the other hand…

To clarify: This scenario is super specific and not really the main focus. It just got me thinking that I never really know when to nil check or not…

And just to make sure we’re on the same page, what I mean by a nil check:

local house = game.ReplicatedStorage:FindFirstChild(houseName)
if not house then
    warn("ERROR: House not found!")
    -- then return here
end
#2

From my understanding, if you know something will always exist, there’s no need for it. For cases when you’re not 100% sure if that instance will be in existence when that thread executes, it’s probably better to use :FindFirstChild, or in some cases :WaitForChild

3 Likes
#3

I also want to add this is nothing of extra work. You’re not doing extra work. But you shouldn’t overdo it either because then you’re ruining the point of nil check.

1 Like
#4

I don’t really do nil checks that much. If you know something is there, then it is there.

#5

Well, I always suggest to make a :FindFirstChild() or a :WaitForChild all the time when trying to find a new object and then check if its there because if you fail to do so, your script could be stopping working and just break everything. So if I have to answer this, do it when you are not sure that the player has what you are looking for.

#6

Right, I could see in my case where I’ve put all the items neccessary in replicated storage to achieve the loading system, I wouldn’t need to nil check. But I guess I could imagine a scenario where I have hundreds of houses where one might be misnamed and then if I didn’t nil check something could go horribly wrong in-game if I didn’t notice before publishing.

1 Like
#7

How is it not doing work?
In this scenario:

local x = 10
local y = 5
if y == x then -- this check right here is doing work right?

end

And if that’s doing work, then house == nil is also doing work, just checking if house and nil are equivalent.

That’s just my assumption

#8

When I say “extra” work, I say it like that because it seemed like you thought it was heavy on the server, i.e you would lose performance when doing it, but this is not the case.

#9

Yeah, one instance would be negligable. But what if I’m nil checking hundreds of times a minute, or thousands a second. I feel like it could have an impact at somepoint no?

#10

I wouldn’t worry about it. That is why you only do it when you are unsure.

2 Likes
#11

Well, if anyone else has input on this that’d be great

#12

What incapaz said, only do it if there is reasonable doubt that a part/variable may or may not exist, or is nil.

#13

You should only check if something’s nil if you’re reasonably sure it won’t exist for some reason or another (aggressive instance cleanup, streamingenabled and such).

One place you should always, always, always check is at the client/server boundary - if you have RemoteEvents accepting arguments from a client, make sure those arguments are the type you’re expecting. You can use typeof to do this quickly and cleanly, and nil has its own returned data type.

#14

Checking for nil instances are crucial in coding because they can prevent many errors. The only times you check if something is nil is if you’re not exactly 100% sure if the object is existing or not. For example, if you were to make a mining game to mine stone blocks, you would have to check if the stone block exists with the nil check or any references to it, such as SoneBlock.Name will throw a nasty error at you. If too many errors are thrown it can cause lag in your game, because it is spamming the console with unnecessary errors. Another example is to use DataStores. You would have to check if the player has data already stored with a nil check, or you would get errors trying to load non-existent data.

#15

Don’t always use :WaitForChild(). Specifically in the server, because most of the time it’s useless. Be sure that by the time server script start running all server objects have been loaded, they’re implicit. It’s ideal to use :WaitForChild() in the client, because at the start of the game, when the player joins and everything is still loading, objects take time to replicate from the server to the client which is why you need to wait for them.

1 Like
#16

I say use it when necessary, if this is blocking server-side simply spawn spawn(function() end)) a new thread!

#17

Unrelated to original question, but how do you ensure that all server objects have loaded when server scripts start running. Or do you not have to? I’m not sure what you mean by they’re implicit.

#18

If a script makes a part, then that’s a good time to use WaitForChild(), if the parts already exist in workspace, and nothing removes/renames/creates it, then it’s okay to just do game.Workspace.PartName, as there is no change of it going anywhere on the server. On the client is where you would want to use WaitForChild on that kinda stuff though.