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

Update error handling #54

Open
Derpthemeus opened this issue Jun 2, 2019 · 0 comments

Comments

Projects
None yet
1 participant
@Derpthemeus
Copy link
Member

commented Jun 2, 2019

As brought up in some PR comments and Slack discussions, it may be a good idea to review how we're handling errors. Some changes I suggest include:

  • Any method that currently returns/resolves undefined to indicate failure should instead throw/reject errors. This would align with standard error handling paradigms and would allow us to include more information about each error.
  • We should log any unexpected errors (i.e. not caused by missing optional fields in API responses) so we can find and fix them faster.

We may also want to change how the server sends errors to the OS firmware, but these changes may be backwards incompatible.

  • We should be more transparent about errors when sending information to the OS firmware. Instead of setting the watering scale to 100% server-side, we should indicate that the scale could not be calculated and let the firmware select a default (either using the previously calculated watering scale or 100%).
  • We should use the appropriate HTTP status codes to indicate if a request was successful, errored due to a server issue, or errored due to an issue that the user must correct.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.