This change proposes a different approach to simplifying errors than PR #75 (errors as records). Here we take that approach one step further and completely remove the error code portion entirely, returning only a string in the error case. Is this an anti-pattern, though? Some would argue that this is the case, since users might have to resort to string-matching for custom error handling. Others, however, might argue that the error codes were low value anyways since we expect to only see one or maybe two variants as failures to a single call. In any case, this PR offers an alternative to #75 for discussion sake.
This change proposes a different approach to simplifying errors than PR #75 (errors as records). Here we take that approach one step further and completely remove the error code portion entirely, returning only a
stringin the error case. Is this an anti-pattern, though? Some would argue that this is the case, since users might have to resort to string-matching for custom error handling. Others, however, might argue that the error codes were low value anyways since we expect to only see one or maybe two variants as failures to a single call. In any case, this PR offers an alternative to #75 for discussion sake.