Log method for LogService

Feature Requests Engine Features
#1

As a Roblox developer, it is currently too difficult to display an error message in the output without exiting the thread and it is impossible to display an info message (blue-text) in the output.

At the moment if you want to display an error without exiting the thread you need to call the error function in a separate thread.

local function safeError(message)
	spawn(function ()
		error(message, 0)
	end)
end

safeError("This is a safe error")
print("Success")

error("This is not a safe error", 0)
print("Failure")

Ideally it would be nice to have a method for logging to the output as a member of LogService.

local logService = game:GetService("LogService")

logService:Log("This is an error", Enum.MessageType.MessageError)
logService:Log("This behaves like print", Enum.MessageType.MessageOutput)
logService:Log("This is a warning", Enum.MessageType.MessageWarning)
logService:Log("This is for information", Enum.MessageType.MessageInfo)

The default for MessageType being MessageOutput.

We already have similar methods under TestService, however these of course include test information.

Addressing this would make it much easier to debug different parts of our code, or to display information in a format which is more suitable.

19 Likes
404 HTTP Request
#2

I would like to point out a life hack I use to make “errors”, which you can use in the meantime.

local F = Instance.new'BindableEvent';

F.Event:Connect(error);

local function SafeError(Err)
    F:Fire(Err, 0);
end;

SafeError('Lmao what');

Spooky, but it works.
Although native support for it would be great.

2 Likes
#3

Can you provide specific examples of why you want to do this? I would not want this behavior because then I can’t tell if an error stopped the thread’s execution or if it simply continued on. In my mind, an error should mean “something went horribly wrong, stopping execution” whereas a warning means “something slightly bad happened but the script will carry on.”

3 Likes
#4

Using this method to throw an error would not include the stack trace, it would simply display the text in the output with the corresponding color for MessageType.

I’ve a few general use cases for such a feature.

  • Undoing actions - I may complete an action, attempt to do something which could fail and therefore undo that action. I still want to display an appropriate error message to suggest the action could not be completed.
  • Run multiple erroneous functions simultaneously - I may wish to call functions back to back without halting if one of them errors.
  • Callbacks - A callback could error so it would be wrapped in a protected call. If the callback did error I want to display it appropriately before continuing the process.
  • Multiple errors - I may want to throw multiple errors for different bits of invalid data.

The above can be applied to many specific cases such as unit testing, synchronous event handling, etc…

Currently I am working on a plugin that generates a model, prompts a user to upload it and then removes the model. The upload process may fail in which case I want to display the error and remove the model. Luckily in this case I can remove the model first and then display the error, but if I wanted to do something that would cause the thread to yield then this becomes an issue.

A lot of existing languages offer similar features, JavaScript for example offers console.error and Java System.err.printLn

This all goes without mentioning the benefits of being able to display information as well. A specific example I have for this is so my plugin can display when it’s doing something such as inserting a model or initializing itself.

3 Likes
#5

logService:Log(“Hello world”, Color.fromRGB(255, 0, 0))

How 'bout that?

1 Like
#6

The intention would be for this method to run alongside Documentation - Roblox Creator Hub

I think allowing arbitrary colors, while fun, would get confusing.

2 Likes
#7

That would be up to the developer’s will and responsability still.
For example, one could print a message in green if the script was sucessful in doing task X or task Y.

#8
#9

I’ve had use cases for this consistently come up, albeit in the same context (so it’s the same rationale behind each use case, rather than a diverse set of different cases). There are a number of things I like to do with output logging and for now I use the TestService methods, but the fact that they force [TestService] to be at the start of the message is less than desirable.

Because I only use TestService for info logging (blue text), there is a jarring inconsistency between my messages: print statements, warnings, and errors all display with the text I input, but any info logging is displayed as [Test Service]: text (or however it formats it).

Here’s my overall desires:

  • The ability to use info logging (blue text) without the prefix. Color coding of messages is important to me as it not only improves readability in the console, but it also implies certain messages have different impact (info tends to be used for more important statements whereas print is effectively the equivalent of trace logging, for instance). I don’t care that it was sent by the test service, I don’t need that information there.
  • Error color for some issue that isn’t necessarily a code problem, but is a critical issue otherwise (e.g. a player’s data is corrupt when I load it. I don’t need a stack trace for this because it’s not a script error, it’s a data formatting error.) In the context of the data format error, I will manually terminate the function call, but I need that script to keep working because otherwise that means the server is effectively bricked since the script will have been terminated if I use the stock error function.

Under these concepts, implementation of an info function alongside print and warn would be more than welcome. error as it is should be okay, since as mentioned by @Seranok, most cases of explicitly calling error will want to include a trace or otherwise use stock error logging because it will terminate the script.

I concur with OP in that the ability to send messages of all four types via LogService is a more than welcome change. (Un)fortunately, there is no critical issue caused by being unable to do this, it’s an irritation at best.

5 Likes