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

Standardize on raised error formats #294

Open
starbelly opened this issue Dec 31, 2021 · 0 comments
Open

Standardize on raised error formats #294

starbelly opened this issue Dec 31, 2021 · 0 comments

Comments

@starbelly
Copy link
Member

Currrently, the shape of errors is non standard. In some providers a function may match on {error, Reason} and return raise Reason, others may return raise with the entire tuple.

Further, there's a lot duplicate format_error/1 clauses. Most notably are errors raised around hex operations. One idea for this in particular would be to modify rebar3_hex_client functions to take a module name and raise a provider error vs returning one. This would clean up the provider code and could provide context (i.e., it was a hex api related error) that would allow for generic format_error clauses in rebar3_hex_error/1. The only rub with that idea is we lose the context of the task (e.g., publish, retire, etc.).

Regardless, even if we have to a format clause unique to each task, we could still have some standard format_error helpers to help shrink the code if we simply provided a little more context about the error. For example we could standardize on ?RAISE(task, hex, Error}), thus at the very least we would know it's a hex api related error and safely reach out to a error format helper.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant