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

feat: handle caller errors using errors as values #469

Merged
merged 2 commits into from
May 21, 2024

Conversation

Manason
Copy link
Member

@Manason Manason commented May 13, 2024

When the caller of an API function passes an illegal value (equivalent to a 4xx HTTP error), changing existing assertions to instead return success, errorResult to allow the caller to handle those errors or else fail silently. This is a departure from assertions, which require errors to be caught and handled or else blow up the stack. The thinking is that this default behavior of silently failing is what callers would prefer.

assertions continued to be used for types of errors that clients should not be handling, but are rather indicative of a bug. These do not have an error code as they are unexpected faults in the program and therefore should only be handled for purposes like logging, which do not require differentiation among the causes of the assertion violation.

Also introduced a types.lua to hold general types which don't really belong anywhere else. We can consider moving all types here in a future PR.

server/player.lua Show resolved Hide resolved
@KostaZx KostaZx merged commit 0ad1ef4 into main May 21, 2024
4 checks passed
@Manason Manason deleted the better-error-handling branch May 21, 2024 16:24
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

Successfully merging this pull request may close these issues.

None yet

3 participants