Coroutine.yield() silences errors

[gillern]

After you call coroutine.yield(), errors just don’t show in output anymore @woot3

Repro:

local c = coroutine.running()
delay(1, function()
    coroutine.resume(c)
end)
coroutine.yield()
print("done") --This prints
print(2+e) --The error for this doesn't show

[blobbyblob]

“Note that resume runs in protected mode. Therefore, if there is any error inside a coroutine, Lua will not show the error message, but instead will return it to the resume call.”
https://www.lua.org/pil/9.1.html

I don’t believe roblox changed up their implementation for resume from the out-of-box version of Lua.

Edit: adding assert should be an easy way to get your desired behavior. assert(coroutine.resume(c));

[woot3 (Woot)]

While tagging me will certainly bring this to my attention quicker, in the future, please verify your report is valid prior to doing so.

As @blobbyblob has explained this is intended behavior.

[Autterfly]

Looked around for a bit to find this was already a reported issue. Just encountered it myself and had me stumped for a few minutes as to why my code was just stopping at a seemingly normal statement. Turns out an error was being thrown and it was swallowed up because much earlier in the code I had used coroutine.yield() to wait for a bunch of coroutines to finish.

I think a good solution would be to have threads retain their normal error propagation behavior if that’s how they were first created.

[Anaminus]

yield isn’t the problem. It happens because you didn’t handle the values returned by resume:

PSA: You can get errors and stack traces from coroutines

Consider Quenty’s fastSpawn implementation: function fastSpawn(func, ...) assert(type(func) == "function") local args = {...} local count = select("#", ...) local bindable = Instance.new("BindableEvent") bindable.Event:Connect(function() func(unpack(args, 1, count)) end) bindable:Fire() bindable:Destroy() end An event, specifically a BindableEvent, is used to spawn the function in a new thread. Events have no delay (hence “fast”) and emit errors on the first resume of the thread. …

The right solution to this would be a new function that resumes a thread while handling errors for you:

Add resumeThread global function

resumeThread(t: thread, args: ...any) The resumeThread (name pending) function behaves similar to coroutine.resume: it receives a thread and a number of arguments, and resumes the thread, passing the arguments to the thread. The difference is that no values are returned, and errors are handled by the engine, in the same way as spawn, delay, events, and so on. I believe that the addition of this function is an essential piece to properly integrating coroutines with the Roblox engine. Developers…

[Autterfly]

I see. I was aware resume was eating up the errors but I considered the behavior of doing so even on threads that weren’t started by the user a weird implementation detail. I do like the idea of a separate function for this kind of behavior, but I would also prefer Roblox change it to still propagate errors from those kind of threads.

It doesn’t seem obvious to the average user that errors would behave like this, in my opinion.