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
We recently moved to a source error style in the client crate and CLI.
In the web client, in order to return errors, a conversion to JsValue is required. In most places (if not all), errors are converted to this type by converting the error type to strings (example). This means we lose source error information because only the top level error variant is converted to string.
To solve this, we may implement a utility function (and a wrapper type) that does the conversion appropriately, where the error chain is correctly conveyed in the converted type. There could be places where we might still want to map errors and not leak internal details, but in general this strategy should be applied throughout the whole crate.
We might want to implement
We recently moved to a source error style in the client crate and CLI.
In the web client, in order to return errors, a conversion to
JsValue
is required. In most places (if not all), errors are converted to this type by converting the error type to strings (example). This means we lose source error information because only the top level error variant is converted to string.To solve this, we may implement a utility function (and a wrapper type) that does the conversion appropriately, where the error chain is correctly conveyed in the converted type. There could be places where we might still want to map errors and not leak internal details, but in general this strategy should be applied throughout the whole crate.
We might want to implement
See this example of a wrapper type and error chain reporting (provided by @PhilippGackstatter).
The text was updated successfully, but these errors were encountered: