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

New Issue

2022-11-22T18:34:19+08:00

luiz00martins commented

2022-11-22 18:34:19 +08:00

(Migrated from github.com)

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.

### 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](https://github.com/SquidDev-CC/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: ```lua --- ... 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 ```lua 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

2022-11-23 01:10:36 +08:00

(Migrated from github.com)

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.

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.

👍 1 👀 1

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GitHub/Basalt#39

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

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

Minimal Working Example

Describe the solution you'd like

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