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

Continue execution after error is thrown while flushing store updates #88

Open
zzhabib opened this issue Oct 3, 2023 · 1 comment
Open

Comments

@zzhabib
Copy link

zzhabib commented Oct 3, 2023

I've noticed that whenever an error is thrown from a function subscribed to Store.changed, the execution is stopped and the rest of the functions subscribed to Store.changed do not get fired. This might be more of an issue with Signal.

Is there any way I can ensure that the store update flush will continue even if one of the subscription functions throws an error? I don't want my entire game to break because of one error being thrown.

@Pluviolithic
Copy link

Pluviolithic commented Dec 19, 2023

A trivial fix for this would be to call each listener in a separate thread, but that doesn't fit with the spec file since listeners are meant to be called in order. Spawning the listeners in separate threads would not guarantee order.

An alternative would be to catch errors with a pcall and then throw them as errors in separate threads:

function Signal:fire(...)
	for _, listener in ipairs(self._listeners) do
		if not listener.disconnected then
			local success, message = pcall(listener.callback, ...)
			if not success then
				task.spawn(error, message)
			end
		end
	end
end

But this is expensive and doesn't seem to fit what Rodux is going for.

You could stop here and say "just do proper error handling in your listeners," which is fine, but I have a couple qualms about that.

  1. It doesn't fit the pattern set forth by RBXScriptSignal connections. This library is patterned after Redux, so it would make sense to not necessarily follow the norms set forth by Roblox, but Roblox conventions still remain a valid consideration.
  2. Leaving error handling entirely up to the developer is not always the best course of action. I could simply pcall all my listeners, but that would be clunky and not an ideal setup for actually handling problems. I could try to handle every single error that could pop up, which I do. But I have run into issues in production that I didn't predict or test for. This can cause serious problems because the errors cascade and block other important behavior from executing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@zzhabib @Pluviolithic and others