That’s defined behaviour, it will always exist on the server, possibly not on the client.
1 Like
I’ve been scripting for a while now, but I’ve never seen Instance.new() return nil… Even if the map is big and there’s a lot going on in the scripts.
You don’t have any idea what you are talking about. Instance.new will return an Instance as long as it does not throw a error. Yes, it’s true that creating an Instance doesn’t mean it will successfully replicate to all or any clients, but you still created an Instance and it’s not going to randomly be nil. It will exist on the server even if the “local” “allocation” “fails”.
This cannot cause Instance.new to return nil.
1 Like
So therefore using it locally is undefined!
1 Like
No. Instance.new is perfectly defined behavior. If it does not throw an error, an instance was created. It cannot possibly be nil. It does not matter what you say about server or “local” “allocations”. There’s no point in checking if the return value is nil because if you have a return value it’s absolutely guaranteed not to be nil. If the server side is out of memory then it will throw an error and you won’t even get to check if the return value is nil or not because it won’t exist.
1 Like
When anyone starts a sentence with “You don’t have any idea what you are talking about” says to me I have nothing left to say. You are beyond reproach. Continue relying on documented well defined behaviours and never check anything yourself. Good luck with that.
1 Like
I’m not sure what the point is of telling me that I’m “beyond reproach” here. I said you don’t have any idea what you are talking about because you don’t. If that makes you close up and refuse to listen to what I have to say, then so be it.
Yeah, I totally believe that you’ve seen Instance.new return nil with your very own eyes.
1 Like
Whether I have or not, I will never utterly rely on it. It is bad practice to assume anything when it comes to code, clients, and servers.
1 Like
You seem to be assuming that Instance.new can return nil, though. Because “it is bad practice to assume anything”, you assume that infallible operations can fail. How ironic.
Here’s a funny thing: if instance.new returns an object with a metatable, it can override ~= nil to do something ridiculous like throw an error or crash your game. Since you can’t assume anything, you can’t rule out this happening. Maybe you should check for metatables too, or use rawequal.
Belief in infallibility is what bugs are made of!
1 Like
No argument here, being overconfident in something you shouldn’t be is a huge source of bugs. But considering we’re talking about a single function here, and it’s documented to never return nil and known to raise an error whenever the instance can’t be created, and considering your argument about “local allocations” is completely invalid because that’s not how replication works (the server never depends on an allocation being made on any one client), it’s pretty fair to believe in this very specific case, this specific function will never return nil.
Claiming that it can, just because it’s dAaAAangerous to AsSUuUUUmE when it’s clearly documented as never returning nil at all (notice the lack of ?), is a big source of cargo cult programming which I personally despise.
1 Like
It isn’t recommended by Roblox Staff to use the parent argument for Instance.new.
That’s about all I can see (I don’t use DataStore2, so I can’t confirm if your code is well-protected against data loss).
If your code is already functional, I recommend re-directing this to #help-and-feedback:code-review instead of this category
2 Likes
Documentation means naught, only under an infinite testing environment can the pure return value ever be truly defined. Saying “It hasn’t crashed yet” is not enough.
1 Like
I never knew that category exists. But thank you. I will consider that next time when I want feedback.
Or disassembling the Roblox binaries and seeing that there isn’t even a code path in Instance.new capable of returning nil.
Seriously, go grab IDA64, load up the Roblox engine, and see that Instance.new doesn’t have a single code path that can push nil onto the Luau stack. Or if you can’t do that, go ahead and test it yourself in Studio. Create instances in an infinite loop. Eventually it will error, and Studio might even crash, but it will not return nil.
1 Like
That last byte of allocation, or operation, is the one to shoot your whole leg off! It might not be Roblox’s superb system, the operating system has many cores, thousands of threads, all competing for operation time and execution windows.
1 Like
Dude, literally in like the history of development I have never seen anybody say that Instance.new() return nil, and same for me.
This argument is getting off topic, could you please try to help the OP with their issue instead.
3 Likes
Over and out, I have nothing left to say anyway.
1 Like
Anyways the only suggestion I have is not stacking two things together like this:
local CurrencyData = Datastore2Module("Currency", plr):GetTable(DefUserData.Currency)
Edit: I don’t know how this will affect any type of performance.
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.