-
Notifications
You must be signed in to change notification settings - Fork 0
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
Errors within backend #16
Comments
I was about to make a list of all possible errors we can give, and realized most of them should be code 400 (Bad Request). The only one I'd use a diferent one is for "Lobby not created", using code 404. This is an error when trying to join a game that was not created. |
I think I agree with this approach |
And regarding ilegal game-states? Should we add some checks and return |
How is an illegal game state happening? More importantly, how would we detect it? 'Cause if it happens it's probably a bug, and if we can detect it we can probably just fix the bug... 🤔 |
Well, by checking it, we could detect it. We could have a log of all status 500 given... |
But how do we check it? If we know how to check it, we would do so before saving the game and assume we had a bad input, right? Which would be a 400? |
It seems like we could close this issue then... Maybe leave it open only to remind us to change the status to 404 for when the game doesn't exist. |
Wait, I thought we already gave a 404 when the game doesn't exist |
Description of the current situation
Right now the only errors that the backend handle are those that come from bad requests.
If, somehow, an invalid game-state is stored, the game could easily give an exception rather than informing of the error. For example: Having a game-state with a single
:player-id
gives an error.Description of the wanted situation
I think backend should also return error messages handling those errors, so we know why something went bad, in case it happens. As I see it, this will let us way more easily find any bug.
Considered alternatives
We could leave it as it is. Tests and ensuring requests are valid should avoid this to ever happen.
Additional context
I say so after realizing that there are some assumptions that are never checked. That's because the state that would make such assumption happen isn't achivable under normal circumstances.
Also, I think we would probably need to tell appart from errors from a bad request and errors from an invalid game-state (that we won't know how it happened in the first place).
The text was updated successfully, but these errors were encountered: