Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

love.threaderror isn't called if error message is empty #1775

Closed
EngineerSmith opened this issue Feb 12, 2022 · 5 comments
Closed

love.threaderror isn't called if error message is empty #1775

EngineerSmith opened this issue Feb 12, 2022 · 5 comments
Labels
bug Something isn't working good first issue Good for newcomers

Comments

@EngineerSmith
Copy link
Contributor

local t = love.thread.newThread([[
error()
]])
t:start()

The above code doesn't show default love.threaderror as expected (or a custom set love.threaderror). Not a massive bug - but something to be aware of if no error message is given

@slime73 slime73 added bug Something isn't working good first issue Good for newcomers labels Feb 13, 2022
@thegrb93
Copy link
Contributor

Looks intentional

if (error.empty())
return;

@zorggn
Copy link

zorggn commented Feb 13, 2022

But if you look at the code above that, you'll see this:

if (!error.empty())
onError();

I might be wrong, but, onError gets called by that if error's not empty... yet inside onError, it is tested if it's empty again, which it can't be?

@thegrb93
Copy link
Contributor

thegrb93 commented Feb 13, 2022

There's probably other cases onError may be triggered

@zorggn
Copy link

zorggn commented Feb 13, 2022

In any case, i'd assume that an empty error call should still pass an empty string to threaderror since an error was raised.

@slime73
Copy link
Member

slime73 commented Feb 13, 2022

Yes, I think the core problem with the code is that it's using the error string variable to store the error message and as a flag to check if an error has occurred, so it assumes there's no error if the error message is empty. It should fix the bug if those two concepts are split up (for example by adding a didError boolean variable or something.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

4 participants