You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Currrently, the shape of errors is non standard. In some providers a function may match on
{error, Reason}
and return raiseReason
, 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.The text was updated successfully, but these errors were encountered: