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

Specify error cases #134

Open
kelunik opened this issue Jan 6, 2017 · 6 comments
Open

Specify error cases #134

kelunik opened this issue Jan 6, 2017 · 6 comments
Milestone

Comments

@kelunik
Copy link
Member

kelunik commented Jan 6, 2017

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.

@bwoebi
Copy link
Member

bwoebi commented Jan 6, 2017

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...)

@kelunik
Copy link
Member Author

kelunik commented Jan 6, 2017

It makes sense to explicitly specify negative integers being unspecified.

Why does this make sense?!

@bwoebi
Copy link
Member

bwoebi commented Jan 6, 2017

Looks like we should also include 0 here, the underlying loop backends don't seem to be able to handle that well.

@joshdifabio
Copy link
Contributor

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 Driver which validates and sanitises inputs to ensure that all drivers treat these edge cases the same way.

@bwoebi
Copy link
Member

bwoebi commented Jan 6, 2017

@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).

@bwoebi
Copy link
Member

bwoebi commented Jan 6, 2017

@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.

@kelunik kelunik modified the milestone: 1.0.0 Jan 8, 2017
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