How to Navigate to Error Lines Using debug.traceback() or a String

Help and Feedback Scripting Support
#1

Is it possible to click on the print (or error) output using debug.traceback to navigate to where the error occurred?

By setting loadstring’s second argument "chunkname" and associating the script instance with setfenv, we can easily navigate to error lines even if they are generated by loadstring. Here’s an example:

local script = workspace.TestScript 

local fn = loadstring(script.Source, script:GetFullName())
local wrappedFn = setfenv(fn, setmetatable({script = script}, {__index = getfenv()})) 
wrappedFn()

-- workspace.TestScript.lua
print("Hello world!")
print("Hello world!!")
print("Hello world!!!")
print("Script:", script)
error("Hello world!!!!")
I got the idea from Kampfkarren’s monkeyRequire.

image

By setting "script" in loadstring’s environment to the script instance,
it becomes easier to navigate to where prints and errors occur.

Now, I want to achieve the same for errors in pcall or task.spawn using debug.traceback.

local function fn()
	error(debug.traceback("Error"))
end

local function fn2()
	fn()
end

fn2()

image
Just using the error function, the output recognizes the error as a single line instead of separate lines.

#2

I don’t think I’m understanding your post correctly. debug.traceback returns a string of the traceback and outputs it to console using error, that’s it. The actual clickable traceback is the one that shows up on the console with blue text. I ran the same code as you but without the debug.traceback, does this not show up for you?

image
image777×91 17.3 KB

If you do not, are you filtering out the Information type in your console?

#3

I think you are misunderstanding what debug.trackback() is actually doing. So the idea of debug.traceback is not to show the navigation of the specific error calls (as an error has not occurred officially), but instead in more complex cases, the navigation of where the potential error occurred especially - in metamodules where code is existing in some annoying ethereal space or the entire chain is overall complex, and can be reached through many routes. In these cases however, the errors are not runtime errors but instead whats known as “errors in logic” meaning that the desired outcome was usually not reached - in these cases, we may want to know the path used to reach such a conclusion and not entirely be bothered with the details of actually navigating towards it.

As you have done error(debug.trackback(“message”)) what you have actually said is “raise an error in angry red writing here and stop the execution”, when in reality debug.traceback() returns a string which is the traceback towards the initial point of execution - in other words, something you can visually follow along with. If I did this code for example, the traceback messages would differ but I may achieve my result of knowing the exact route the code is taking:

print("Hello world!")


local function fn()
	print(debug.traceback("Error"))
end

local function fn2()
	fn()
end

local function fn3()
	fn()
end

local function fn4()
	fn3()
end

fn2()
fn3()
fn4()

In each case fn() is being used uniquely, and the output will now represent this. In short, the answer is no, as in most cases a proper traceback is something entirely unique (which is not really a string, but a complex text class in itself relating to the editor). In short - the desired behaviour you want is not achieved through this.

#4

Sorry, my question lacked details. When using task.spawn or asynchronous operations (signals),
the error information is not printed.

I want to make it easy to navigate to the error line, even if the traceback is printed from another thread.

local function fn(traceback)
	error("Error" .. "\n" .. traceback)
end

local function fn2()
	task.spawn(fn, debug.traceback("From: "))
end

fn2()

image
image833×186 17.8 KB

#5

Even though this might seem trivial,
when using the signal module across multiple scripts or chaining asynchronous tasks,
I have to manually check each outputted string and line number one by one using debug.traceback to find where the error occurred in the thread.

This is cumbersome. I just want to be able to click and go directly to the error line.

#6

But it is - on line 2. Click on the blue text right there to navigate to that line.

Are you trying to navigate to line 9 in this case? If so, for what reason? It is not running on the same thread as the main thread anymore, plus I cannot find a reason on why you want to do so in the first place.

Again, debug.traceback just returns a combined string of traversing stacks of the current/provided argument. Studio console is the one actually providing you with the clickable “links” whenever an error has occured.

#7

For signal modules, I sometimes need to find where Signal:Fire() is invoked

With signal chaining, the error traceback becomes too long when using debug.traceback, making it tedious to check the line numbers (unable to navigate by just clicking)

Loadstring has a trick where you can set the fenv to make it possible to click on an error or output, and go to the corresponding line.

I’m wondering if there is a similar trick for debug.traceback

#8

I haven’t heard about this, nor do I know any methods of doing this. If you find this out, it would be nice to know.

Regardless, the default Roblox behavior when it comes to firing signals does not even do that. If you insist on breaking this parity, you can probably get away with creating your own console through the use of ScriptEditorService. I say probably because I haven’t fully dived into using it myself, but it seems possible.