Imagine that I implement a new big feature in the newest update of my game. I tested the code as much as I could to find bugs, but I’m still unsure and think there’s some really tricky edge-case that I haven’t found yet or is really hard to reproduce. Let’s also imagine that if that unknown edge-case does occur and an error is thrown, then it breaks the game in a significant way (e.g. stops a queue) unless I pcall the function. Would using pcall in this case be justified?
I think it would be justified if the intention is just to make sure the game still runs and I log the errors and eventually remove the pcall once all edge-cases are found and solved.
No. You’re running away from your problems instead of confronting them directly. If the error stops a queue, irregardless of the pcall, it will still stop the queue. If your code is so unstable, then work to make it stable. The only time pcall should be used is in places where the environment is out of your control, e.g., mass change of a selection of Instances, or making requests to a server / using events that connects to Roblox’s endpoint.
wow, this came off as harsh, that wasn’t my intent sORRY D:
Ok, by unstable code I meant that a really rare/hard-to-find edge case exists that you haven’t found the repro to so you can’t fix it yet. When you make a really big new feature that’s complex you can test it all you want, but sometime in the future someone’s going to use it in a way you didn’t expect or some edge case you didn’t know was possible occurs and an error is thrown. Also pcalls can be used to continue a queue if it’s a queue that calls functions.
I think a more practical example case would be a round-based game system. Like Murder Mystery 2, once a round is over, the game restarts and a new round begins - and this is facilitated by a loop. If a rare edge case occurs and an error is thrown in the loop, then the entire game is broken as the next game round will never start. I could use a pcall to catch this very rare case then start the next round - is this not a justification of its use?
I also meant that I think this implementation is ok so long as it’s used just to make sure the game continues to run and to weed out and log errors (where hopefully the edge case could be found). So more as a temporary thing until these really rare cases are found.
Yes. In fact, this is a perfect use case of Pcall. Not only will you be able to avoid the error propagating, you will also be able to account for the error, describe an alternative case for when the error occurs, and perhaps even catch when the error occurs and work out a fix.
Personally, I’d still say no. We know for a fact that any basic Lua behavior like arithmetic operations or calling functions is never going to error on its own, so we can use if statements to catch any error cases before they occur. It’s best to have the foresight to know where errors can occur in your code and making sure that they don’t instead of slapping a pcall() onto the problem and calling it good.
Through my decade-long experience with Lua, I’ve come to find there are three acceptable uses for pcall:
You’re running code that may error and is out of your control, i.e. player:IsInGroup(). This method makes a call to Roblox APIs behind the scenes and may error at some point, so you need to catch that error using a pcall and properly error-handle it because there’s literally no other way to do so.
You’re trying to get some information about the environment you’re running in and can do so by checking if a specific method errors. For example, if you call HttpService:RequestAsync and it errors, you know the place doesn’t have HTTP requests enabled.
You’re running code you wrote that may hit a condition where it needs to exit because you detected that something went wrong and are throwing errors yourself using assert() or error(). This would usually be the case if you’re handling user input or data from an endpoint and something about it would get your program into an unstable state.
Anything other than that generally hints at an underlying problem with your code that should be fixed. If you’re writing code and don’t know whether or not it’s going to error, that’s not a good sign and you should probably be overhauling your code.