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
The current implementation of Display for Error forwards to the inner type's implementation of Display if there is one. However, it is preferable not to do this, for two reasons:
if the user wants the string representation of the inner error, they can always call .source()?.to_string() instead.
When formatted with tools such as Anyhow, the error message ends up duplicating the same information twice, e.g.:
Error: failed to refresh syndication feeds
Caused by:
0: incomplete utf-8 byte sequence from index 5
1: incomplete utf-8 byte sequence from index 5
It would be better if the error displayed what went wrong instead of why it went wrong, producing more helpful traces like this:
Error: failed to refresh syndication feeds
Caused by:
0: failed to parse Atom feed
1: incomplete utf-8 byte sequence from index 5
Now the error message tells a very clear and unambiguous story of exactly what happened. It makes it much easier to debug and is more friendly for users.
Note that this applies even to variants other than Error::Utf8 and Error::Xml. For example, the trace of an Error::Eof would better look like this:
Error: failed to refresh syndication feeds
Caused by:
0: failed to parse Atom feed
1: unexpected end of input
Than what it currently looks like:
Error: failed to refresh syndication feeds
Caused by:
0: unexpected end of input
What had an unexpected end of input? The error doesn't tell you.
The improved trace can be implemented by having source() return a new (potentially private) type EofError which Displays as "unexpected end of input".
The text was updated successfully, but these errors were encountered:
The current implementation of
Display
forError
forwards to the inner type's implementation ofDisplay
if there is one. However, it is preferable not to do this, for two reasons:.source()?.to_string()
instead.It would be better if the error displayed what went wrong instead of why it went wrong, producing more helpful traces like this:
Now the error message tells a very clear and unambiguous story of exactly what happened. It makes it much easier to debug and is more friendly for users.
Note that this applies even to variants other than
Error::Utf8
andError::Xml
. For example, the trace of anError::Eof
would better look like this:Than what it currently looks like:
What had an unexpected end of input? The error doesn't tell you.
The improved trace can be implemented by having
source()
return a new (potentially private) typeEofError
whichDisplay
s as "unexpected end of input".The text was updated successfully, but these errors were encountered: