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