I really like this idea! I've been thinking about some stuff along these lines in regards to the return result from main issue that doesn't really make it any nicer for users because those errors use debug, not display...
-
-
Replying to @spacekookie
Yea, it using Debug isn't really ideal.
@davidtolnay wants to add an `is_termination()` method to Formatter that would let you write debug impls that behave differently when being rendered by main, and I've told him I'm down to help write the RFC for it, but thats a long way off.1 reply 0 retweets 1 like -
For now I think the correct pattern is to have an Error Reporting type that is what you return from main, rather than errors themselves, and it has a debug impl that is really a display impl for main.
1 reply 0 retweets 1 like -
Replying to @yaahc_ @davidtolnay
Agreed, that would be much better. Tbh having a debug formatter that behaves differently feels a bit yikes and like we're gonna regret that even more than the correct errors using debug issue lol.
1 reply 0 retweets 2 likes -
Alternatively, to what extent can these "error return formatter" be auto derived? Might be worth looking into what kind of ergonomics we can have there
1 reply 0 retweets 1 like -
It's possible to write a wrapper that redirects Debug to Display. Overall, I agree that rushing stabilization to use Debug was a great mistake. That formatter method sounds like hack. (But thanks God at least that is possible.)
2 replies 0 retweets 1 like -
I strongly disagree that it was a mistake, Display would be worse. In order for applications to have control over rendering cause chains, error types are required to *not* print their causes from the Display impl. The right approach is exposing is_termination on Formatter.
1 reply 0 retweets 1 like -
Huh? I haven't heard this rule yet. Where is it documented? Looks like I have every single library wrong. Anyway, unless there's some kind of new attribute for derive(Debug), it looks like implementing errors will be a huge pain.
1 reply 0 retweets 0 likes -
Well think about how
@yaahc_'s proposal at the top of thread would be impossible if every layer of your error were incorrectly always printing every lower layer of the error too. There would be no way for a library to iterate the chain and print in the intended order and layout.1 reply 0 retweets 1 like -
That's true, this should be documented better I think. I will need to fix all my stuff now. :) Regarding is_termination() - makes sense now, but unless I'm missing something, people will have to implement Debug manually, or there needs to be a new derive or attribute, right?
2 replies 0 retweets 1 like
anyhow::Error prints using the Display impls of the cause chain so there isn't a need for a new derive at each level other than Display, which already exists in the thiserror or displaydoc crates.
-
-
So the intention is that people will use anyhow:: Error or some other wrapper type to implement the case when is_termination() returns true?
1 reply 0 retweets 1 like -
That's the idea im trying to push at least.
1 reply 0 retweets 0 likes - 3 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.