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
This is unnecessarily verbose and makes it harder to read the surrounding code. Instead, we should turn each of the probs.*Problem variables from ProblemTypes into functions, and say:
return probs.ConnectionProblem(err)
The text was updated successfully, but these errors were encountered:
I like the idea of having probs.*Problem functions to quickly construct a ProblemDetails of the right type. It looks like some of the ProblemTypes have functions like this already (e.g. BadNonceProblem has BadNonce).
I will add one for ConnectionProblem and convert callers using the explicit ProblemDetails struct instantiation.
Several of the `ProblemType`s had convenience functions to instantiate `ProblemDetails`s using their type and a detail message. Where these existed I did a quick scan of the codebase to convert places where callers were explicitly constructing the `ProblemDetails` to use the convenience function.
For the `ProblemType`s that did not have such a function, I created one and then converted callers to use it.
Solves #1837.
Right now we have a common pattern:
This is unnecessarily verbose and makes it harder to read the surrounding code. Instead, we should turn each of the
probs.*Problem
variables fromProblemType
s into functions, and say:The text was updated successfully, but these errors were encountered: