-
Notifications
You must be signed in to change notification settings - Fork 9
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
Specify error cases #134
Comments
I don't think we need to specify wrong types. It makes sense to explicitly specify negative integers being unspecified. (A zero interval for timers is pretty straightforward … it gets executed again after 0 time, i.e. in the next tick - which is implied by the current wording...) |
Why does this make sense?! |
Looks like we should also include 0 here, the underlying loop backends don't seem to be able to handle that well. |
I think it would be good if all loop implementations handled these edge cases the same way, including numeric strings such as '1' being passed as delays/intervals. We don't want applications breaking when someone swaps loop implementations because the unspecified behaviour is handled different by different loops. Perhaps we could add some logic to |
@kelunik Hmm, doesn't make much sense to have it completely unspecified - I think we should specify that they MUST throw a \Throwable|\Exception (but not what type of Throwable exactly they shall throw). |
@joshdifabio That's not an inherently bad idea, but it will have quite a footprint (e.g. extra function call) [also, not all functions receive args, so we'd have some functions directly being public API, others being protected…] … I'm not too much a fan of it. |
Currently we do not specify error cases apart from invalid watcher IDs, e.g. what happens on a negative or
0
interval for timers, what happens on a wrong type there, etc.The text was updated successfully, but these errors were encountered: