Stream: project-error-handling

Topic: Including `source` in error messages


view this post on Zulip Jake Goulding (Sep 21 2020 at 18:19):

Migrating from quick-error to SNAFU: a story on revamped error handling in Rust mentions that deciding whether or not to have something equivalent to caused by: {source} in an error message is a tough decision.

view this post on Zulip Jake Goulding (Sep 21 2020 at 18:19):

I think it'd be nice if the group could help with that.

view this post on Zulip Jane Lusby (Sep 21 2020 at 18:19):

I have opinions on this that I'd be happy to share

view this post on Zulip Jane Lusby (Sep 21 2020 at 18:20):

I think it boils down to if we think the pattern of having a reporting type and an error type where the reporting type handles the format and the error type handles the content is the best way to go

view this post on Zulip Jane Lusby (Sep 21 2020 at 18:20):

I think it is though there really are those pesky issues around failing to convert errors to reporters before printing them and losing context as a result

view this post on Zulip Jane Lusby (Sep 21 2020 at 18:20):

which _really_ sucks

view this post on Zulip Jake Goulding (Sep 21 2020 at 18:20):

SNAFU tends to encourage doing it because it makes the simpler case have more data. But it also gets in the way of the prettier outputs.

view this post on Zulip Jane Lusby (Sep 21 2020 at 18:20):

yea

view this post on Zulip Jane Lusby (Sep 21 2020 at 18:21):

i think being able to do multi line output on CLIs and oneline outputs for logs is a very desirable property personally

view this post on Zulip Jake Goulding (Sep 21 2020 at 18:21):

fun wild idea is to add / use the formatting modifiers for Display somehow

view this post on Zulip Jake Goulding (Sep 21 2020 at 18:21):

{} vs {#}

view this post on Zulip Jane Lusby (Sep 21 2020 at 18:21):

that was @David Tolnay 's idea

view this post on Zulip Jane Lusby (Sep 21 2020 at 18:21):

one second let me link you an old pre rfc of mine

view this post on Zulip Jane Lusby (Sep 21 2020 at 18:22):

https://paper.dropbox.com/doc/Collaborative-Summary-3-Fact-Finding-Pre-RFCs-around-Error-Handling-Reporting--A8BcfCfWgPL0Szl8rqaqnVCeAQ-dnShKo1SsHtdF4Yheeoco

view this post on Zulip Jane Lusby (Sep 21 2020 at 18:22):

the idea is either we add an is_termination flag to std::fmt::Formatter (david and your ideas, approximately) or we introduce a 3rd fmt trait (my idea)

view this post on Zulip Jane Lusby (Sep 21 2020 at 18:23):

but neither one solves the problem completely

view this post on Zulip Jane Lusby (Sep 21 2020 at 18:23):

well, is_termination comes close actually

view this post on Zulip Jane Lusby (Sep 21 2020 at 18:23):

well actually no they both work about the same

view this post on Zulip Jane Lusby (Sep 21 2020 at 18:24):

the problem with both is that you basically end up with competing reporters

view this post on Zulip Jane Lusby (Sep 21 2020 at 18:24):

either you report yourself via is_termination / std::fmt::Report or you get reported via your Display impl and a Reporting type

view this post on Zulip Jane Lusby (Sep 21 2020 at 18:26):

it seems like the only way we could properly fix this is by changing a ton of panic machinery to use specialization to see if the type you're formatting is an Error and if so it would need to convert it to the reporting type, and then you're somehow trying to set the reporting type used by std macros and that doesn't sound good

view this post on Zulip Jane Lusby (Sep 21 2020 at 18:26):

_incase it isn't obvious this is all very half baked rn_


Last updated: Jan 26 2022 at 14:02 UTC