How to prevent a script from aborting when an error occurs (without pcall)?

Help and Feedback Scripting Support
#1

I’m releasing my game now after 3 years and over 25k lines.
Despite many tests, new unforeseen situations always appear, which can generate errors.
The problem is that an error in one line of the script simply ABORTS THE WHOLE SCRIPT.

This means that any function that should be executed after the error will not be executed.
For example, I save my game when the player exits (PlayerRemoving). If any error occurs during the game, even if the player exits the game, they will not have anything saved, as PlayerRemoving will not be executed.

I know that I can pcall to prevent an error from aborting the script. But that only works if I know the snippet that might throw an error IN ADVANCE.

My question is: is there any way to prevent the script from being interrupted when an error occurs WITHOUT PREVIOUS USE OF PCALL?

1 Like
#2

Could you show us what the error is as maybe the best action would be to stop it?

#3

Any error. As I said, an error aborts the script, right?
I would like to have a “generic error trap”, that is, regardless of where in the script an error occurs, I want to trap it, handle it, WITHOUT ABORTING THE SCRIPT.

#4

i don’t want to be rude but first i really doubt that a script with over 2k line is optimized since a game normally is made to have different script, (a script for each thing) and not a script for multiple purpose since it can happen has happened with you having an issue that you don’t know where it is and breaking the whole game.

1 Like
#5

I don’t think that is possible

#6

I keep everything related in a way e.g ui and server in 1 script or module script but use comments to separate the script

#7

so basically all the stuff in only 1 script

#8

Separated for different parts but I usually only have like 3-5 scripts about 2 modules but they are all very organized

#9

but is it optimized? , and as i told i don’t want to be rude.

#10

Well mostly yes usually I like to get a base down that works then start finding ways I can optimize

#11

well tbh then the best i would tell is it to start a whole debugging session even if it take hours is the best to do, because i don’t know any other way out of pcall

1 Like
#12
  1. Syntax errors, compilation errors, arithmetic errors, and a big porition of logical errors are solvable right away.

→ If the script runs into issues right in the beginning, it is definitely not ready for production. The goal is to have a completely clean output upon running.

I know the thread is about unforeseen exceptions, but I’m mentioning this anyway because these errors are in fact the problematic ones. Modules should properly load on require, scripts should execute without issues.

Under the expected circumstances, all functions, even those not called outside an event, should work well.

  1. The code executed during run-time ought to be checked during the testing phase and debugging sessions, as @Kyl3ST said.

→ This leads us to the crucial principle in coding: Always take exceptions in consideration - try to predict the unexpected conditions and situations. If something doesn’t go as planned, act differently.

Like try-catch blocks. This includes type checking and verifying of any client input, always making sure objects exist at the time of execution, and taking special care to proceed in controlled cases, while acting differently in uncontrolled cases.

For instance, ProfileService works flawlessly under normal circumstances, but when meeting the unexpected it is programmed to react without breaking. I always thought it was a great example.

  1. A lot of event based code executes in its own green thread anyway. If something called by :Connect(), :Once(), :GetPropertyChangedSignal(), and similar listeners, errors, that won’t break the whole script. Same applies to code spawned in coroutines or scheduled with task.

The list could go on, however, there’s no pcall for the whole script. Besides, pcall shouldn’t be overused either, because it’s more expensive and intended solely for something unpredictable, bound to occasionally fail. Protected calls are intended for things out of our control.

EDIT. Kyl3ST I accidentally replied to you, hope you don’t mind.

1 Like
#13

well as you told i rarely recommend to use allot pcall i would recommend to use it more for important stuff that really need to run even if it has an error but even for that i don’t really recommend since it can break the game later/earlier. :+1:

1 Like
#15

This isn’t true. An error only closes the current thread. Connections generate new threads, and thus aren’t impacted by errors in the code.

Consider the following:

task.delay(5, function()
	error("oh no")
end)

game:GetService("RunService").Heartbeat:Connect(function()
	print("running")
end)

The RunService event continues running, even after the error.

Now, if the main thread errors before the event can be connected, then it will never run, but, generally, the main thread doesn’t do much that has potential to error, so I wouldn’t be too concerned about this.

If an error occurs somewhere in the script, it won’t prevent the PlayerRemoving event from firing, meaning that the data would still save (unless the error caused unintended behavior, but there isn’t really anything you can do about that). Of course, if there was an unexpected error in the code to save the data, it wouldn’t save, but that is something that can only be fixed by testing and preventing edge cases.

2 Likes
#16

Why the hate for pcall(). What you are asking is what pcall is made to do.

local success, message = pcall(function()
-- your code
end) if message then print(message) end

What’s to hate about that? It will even print the error without stopping the script.
Like asking how to print without using print.

#17
#18

You can utilize warn() and pair it with debug.traceback() to work as a form of error that doesn’t stop execution.

But you should focus on fixing the code itself and implementing failsafes into the code itself to make sure it never throws back an error

warn(`{debug.traceback()} [error statement goes here]`)
1 Like
#20

This is by far the best explanation I’ve had for understanding the behavior of the error() instruction, and I thank you for all your good will. In this way, I mark this topic as solved, so that your explanation can be used by other people who have the same doubt.
Thank you very much.

#21

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.