feat: handle caller errors using errors as values #469
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.