Ability to disable scripts from logging errors or other output

A simple bool button on scripts that disable them from posting any error or prints in the log.
I log all my errors and it gets very cluttry when some insignificant ragdoll script breaks cause the character was deleted before the script got to run etc.

I’d be really nice just to click a button for scripts you don’t care about so they won’t post their insignificant errors all over your F9 screen and/or database.


ScriptContext.Error gives you the script object. You can filter it that way.

It would require going through a list of “illegal names” and would require you to specifically name each script that you don’t want to log. For most parts, scripts that doesn’t do any thing important I let their name remain “Script”.

Also, this would not remove their errors and prints from the F9 screen.

If for some reason you have errors that you allow to happen, you can throw the entire script into a protected call if you don’t care about it erroring (which you do not, assuming by the property?)

1 Like

Having to write:
…embrace every fiber of your script here…
in majority of my scripts is just too much to ask for.

I rather have a cluster of non-relevant errors than having to go through that process.

You could just create a logging module.


local logger = {
    Enabled = true; -- default value
function logger.new(isEnabled)
    return setmetatable({Enabled = isEnabled}, {__index = logger});  

function logger:Print(...)
    if (not self.Enabled) then


function logger:Warn(...)
    if (not self.Enabled) then

    warn(table.concat({...}, " "));


return logger;

Enabled example:

local loggerEnabled = true;
local logger = require(loggerModule).new(loggerEnabled); 
logger:Print("Hello, World!");

> Hello, World!

Disabled example:

local loggerEnabled = false;
local logger = require(loggerModule).new(loggerEnabled); 
logger:Print("Hello, World!");

no output

Easy as that. You can even change this further to have logging functions that work in studio-only etc.

As for errors, you should really add checks for things like the character being deleted etc.


Uhhh won’t this only work on manual errors and not ones in which ROBLOX reports a problem with the code?

If you want to stop errors from ROBLOX’s unstable Web API - use pcall. If there are non-Web errors, then you should fix the cause rather than ignoring it.

If your script errors because a character dies, likely chances are it could be fixed by adding some checks. Not really that difficult.

Having a script randomly break without any indication as to why is a debugging nightmare. Errors exist for a reason. Imagine disabling the errors because you didn’t put the checks in place, only to find that something else has broken the code (and it’s a rare bug!) but not knowing what exactly did. :wink:


Wat? If you don’t set script.Name then how can you be expected to set script.Log? Just set up your environment in way that lets you debug it.

I was confused by your reply because based on OP these errors should be fixed via checks.

I don’t think anyone really gets what I’m aiming for here.
YES, there are a MILLION ways of scripting around this, none of which is good.

The reason I suggested this feature is because it’s easy to use. At the click of a button you disable the script for outputing anything in the log.

I don’t think I’d ever use this. If you have so many errors that it’s becoming tedious to keep track of, perhaps fixing your code would be a better solution than a “sweep it under the rug” approach :wink:


The issue is not that the code malfunctions.
The ragdoll script runs when somebody dies, if you die by being deleted then ofcourse it’ll break cause theres no torso anymore. Trying to “fix” this will only create REAL bugs instead. Trust me, I’v tried.

I’m abit disappointed nobody else sees the potential here.

if char ~= nil and char:findFirstChild("Torso") ~= nil then --codes? end ? edit: sniped nikilis
1 Like

if Character:FindFirstChild(“Torso”) then

Edit: RIP

1 Like

Nvm :sleepy:

Nobody sees the potential in selective logging, just close the thread before I get more generic approaches to illustrative examples.

The reason why no one is agreeing with you is because sweeping errors under the rug is just bad practice. There are a lot of knowledgeable people stating why it is bad. It would be a good idea to listen.

Another big reason why this feature would cause problems is because inexperienced scripters may mistake it as a magic “fix all problems” solution and use it to hide bugs that will lead to more bugs down the road. Adding a feature that creates more problems than it solves just to silence one person’s output wouldn’t help anyone.


I would use this for regular logging. However, the way I have it setup is a level of logging setup, so important logging is a higher value between 1 and 10, then I can change the logging output at any time. I achieve this by Always using a custom function to output instead of using print directly.

Errors, well they need to be fixed, so I would want all those outputted.

It’s not sweeping under the rug, as explained in earlier post.

I don’t think anyone understands why you want your code to break but not produce an error. Why not just fix your code?