Pyroxenium / Basalt

A UI Framework for CC:Tweaked
MIT License
164 stars 28 forks source link

feature: Return true errors upon failure on `basalt.autoUpdate` #39

Open luiz00martins opened 1 year ago

luiz00martins commented 1 year ago

Is your feature request related to a problem? Please describe.

It seems like basalt.autoUpdate() does not return true errors upon failure. Instead, it prints the error itself, and returns normally. This causes some things that depend on true errors to fail, such as pcall or xpcall.

This effectively makes implementing custom backtraces for basalt impossible. As a real example of this, running basalt inside of mbs will not print the backtrace, as mbs expects the program to raise an actual error upon failure.

The main usage I have for this is to log the backtrace:

--- ...

local function log_traceback()
    utils.log(debug.traceback())
end

utils.log('Running main loop')
local ok, res = xpcall(basalt.autoUpdate, log_traceback)
if not ok then
    error(res)
end
utils.log('Execution succeeded')

In the code above, log_traceback and the code inside the if will never execute, regardless of the failure status of autoUpdate.

Minimal Working Example

local filePath = "/basalt.lua"
if not(fs.exists(filePath))then
    shell.run("pastebin run ESs1mg7P packed true "..filePath:gsub(".lua", ""))
end
local basalt = require(filePath:gsub(".lua", ""))

local main = basalt.createFrame()

local thread = main:addThread()
local function yourCustomHandler()
    while true do
        os.sleep(1)
        error("Horrible error") --Error
    end
end
thread:start(yourCustomHandler)

local success, err = pcall(basalt.autoUpdate)
if success then
    -- Currently, it'll follow this path, as though the execution succeeded.
    print('Success')
else
    -- I wish it would follow this path, which is the failure path.
    print('Error: ', err)
end

Describe the solution you'd like

Calling error with the message displayed passed as an argument that can be catched.

NoryiE commented 1 year ago

Hello and thank you, currently i am simulating an error when something unexpected happens. I should probably use 'error' instead, like you said. A bad decision by me.

I will add this into my todo list, currently i'm reworking the objectsystem, which means it will take a bit before i'll add this feature.