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

Error chains are not aware of "non message" error wrappers #6

Open
Southclaws opened this issue Nov 2, 2022 · 1 comment
Open

Error chains are not aware of "non message" error wrappers #6

Southclaws opened this issue Nov 2, 2022 · 1 comment

Comments

@Southclaws
Copy link
Owner

Currently, Fault has this concept of a wrapper that has a message and a wrapper that is just a wrapper with metadata.

The wrappers that only provide metadata and do not provide a useful string message will show up in error chains like this:

<fctx>: <fctx>: account not found: <kind>: <fctx>: sql: no rows in result set

That's a lot of useless noise and is a tough sell despite the benefits of Fault decorators.

What's happening here is each decorator that only provides metadata has no information to return when Error() string is called. So they simply return their name in angle brackets.

So when a top-level Error method is called, and it joins together the entire error chain separated by : (as with most error libraries) you end up with a bunch of wrapper names in between the useful internal error messages.

@Southclaws
Copy link
Owner Author

Potential solutions:

Assume that any .Error() strings that are just matching the pattern ^<\w+>$ are to be ignored.

  • Pros: simple
  • Cons: if anyone else wants to implement Fault decorators, this is a detail you can't enforce easily

Write a simple interface that, if satisfied, indicates to Fault that the type is just a container and does not provide an error string of any value.

  • Pros: also simple, maybe more idiomatic (?)
  • Cons: bit of an abuse of interfaces, it's more of a signal decorator on the type than an actual interface into functionality

Southclaws added a commit that referenced this issue Jan 10, 2023
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

No branches or pull requests

1 participant