Oh I see, can you give some examples? Thanks!
1 Like
A specific example of a valid pcall that does not use a web call is ComputeAsync(), which is used for pathfinding. An error is thrown if the navigation mesh has no vertices to reference to pathfind through.
[Side Note]
This is the most expensive non-webcall method I’ve come across; but this isn’t surprising considering how much it is doing! Most programmers elect to limit the amount of times ComputeAsync() is called by using raycasting or distance/position checks; never call this every frame.
[Edit]
Removed the part about the wording of an asynchronous name since the wording is chosen to relay what is expected when it is called.
2 Likes
i dont get it. How can i use it? Is it a call or fire event or naming it? why . insted of : ?
1 Like
they retrieve a method that datastore (DataStore:GetAsync() in this case) has and then pass explicit self into that method.
Basically. pcall(DataStore.GetAsync, DataStore, "key") is same as protected DataStore.GetAsync(DataStore, "key"), which is same as DataStore:GetAsync("key") (and also protected aswell because its all in pcall)
you could of course use a dumbed down version and use a wrapper function provided below
local success, result = pcall(function()
return DataStore:GetAsync("key")
end)
or just write the result into a pre-defined local as mentioned before.
TL;DR: . is used instead of : because we need to obtain a method to use pcall on and then explicitly pass the object itself to imitate a method call.
3 Likes
i get it now, bassicaly it works like a module or function. But thx i already know it
1 Like
very informative and clear tutorial. really appreciate this, thank you
3 Likes
Very good tutorial goes in depth and explains well!!!
1 Like
Could you elaborate on the variables assigned to the pcall() function? As a non-experienced scripter, I’ve only ever been introduced to the following:
local success, errormessage = pcall()
Is there any purpose or difference in writing “response” in place of “errormessage?”
Appreciated,
vamp
1 Like
var names do not matter, the first arg is a function that can be provided and the other is a list of arguments to be passed to the function, most commonly self comes first. the “list” is known as a tuple
3 Likes
@2jammers is spot on, these variable names can be anything you’d wish.
The main reason I utilise response rather than errormessage is because pcall will return whatever the pcall’d function returned whenever success is true. Hence it would make less sense to name it errormessage since, it may not be an error message.
Example:
local success, response = pcall(function()
return 1
end)
if (success) then
print(response) -- since success is true here, our response variable holds 1, and so '1' is printed
end
1 Like
There is a scenario that I believe wasn’t mentioned: when you connect a function to an event, you don’t want to disrupt that connection. However, if an error is thrown, the connection could be lost. This is why, in my opinion, it’s useful to encapsulate the connected function within a pcall.
Example:
RunService.RenderStepped:Connect(function(deltaT)
local success, error = pcall(Camera.update, deltaT)
if not success then
warn("Critical Error during RenderStepped of camera : " .. error)
end
end)