I have a set of changes I'd like to make around error handling that are somewhat separable and I'm wondering if anyone who has experience with the RFC process has a recommendation on if I should write this as one RFC or many.
Specifically, the changes I want to make are:
backtracefn from the error trait
Trytrait for types to know when they've been propogated so they can generate error return traces via
#[track_caller]and reporters can use generic member access to extract this location data
so like, the return trace and move error trait to core both depend on the member access stuff
("An official way to do Error in
core" is highly desired, but I don't have any thoughts on the RFC implications.)
I'm unsure whether I should write this as 3 rfcs or 1
There are tradeoffs.
In my opinion, I'd say "if the features can be entirely orthogonal, write separate RFCs, it'll make your life so much easier".
also, I wrote the entire first bit already but used a simpler solution that I think we should actually use, is it okay to mark the proposed solution as a placeholder/backup and point to another solution as the preferred one assuming some research is put into it
okay, yea they're definitely orthogonal, cross referencing RFCs it is
But if the features do interact or depend on each other, I think it's preferable to either have one RFC, or at the very least if it's a fairly simple dependency just submit the first and wait before submitting the second.
well, the error return trace one is pretty independent its just implementing it without first doing the generic member access means you'd have to find a solution to the member access concern
the move the error trait to core i think entirely depends on the generic member access to be tenable
Also, first impression: :+1: to removing
backtrace (yay!), :+1: to moving
core (depending on details).
k im gonna focus on the main one then, because that clears the way to everything else
Regarding error return traces, that one I feel interacts heavily with the concept of "context" as well.
I'll add that the first one paves the way to moving error to core, without writing an RFC about moving it to core yet
I would love to have a built-in concept of "add context to an error", somehow.
Or error chaining.
Something along those lines.
well this wouldn't be tied to that
this is kinda the flip side of that feature
Well, there's one interaction.
this is how to get context out of an error
i guess the
track trait is in essence the flip side
Sometimes when people "downcast" an error they are actually looking for a previous error in the chain, not a trait of the error thing itself.
of adding generic context
So, for instance, today, for the first time, I wrote code that uses
downcast method, to get a
std::io::Error out of an
anyhow::Error iff it had one, so that I could get an errno for a protocol that needed errno values.
``` fn downcast_refchain<T: Error + Sized + 'static>(&self) -> Option<&T>;
Personally I would like the core error trait to not have backtraces or other payloads because I like dead-simple error enums. I would specifically like to avoid "contexts" or other "notes on what happened" in the error because I would like the error construction to basically be an error code and nothing else.
is it just iterating through the sources and downcasting? @Josh Triplett
Yes, I think so.
because if so I have the same thing in my errtools crate
which is what i failed pasting above
Effectively, "if this
anyhow::Error came from a
std::io::Error, use that, otherwise, wrap this
anyhow::Error in a
(I think you need a newline after the three backticks)
yea, i just always forget
i feel like a generic "add context to an error" trait would be fraught though
because presumably you'd need a default impl to ignore that info
and it would be hard to know if the error you're adding context to can even handle it
i guess if it acknowledges that it handled it
eeh, ill worry about this later as part of the Track stuff
okay but @Josh Triplett re earlier question that I think got missed
i have two possible implementations for my RFC
and theres one that i think is better because it supports DSTs but its definitely not nearly as clean looking
and i feel like it would distract from the RFC
do you think its cool to use the backup impl as the example throughout the RFC but then in the implementation point to the second solution as preferred assuming it is sound
I think that'll heavily confuse people.
If you have a preferred solution, I would emphasize that, even if you have to say "some details glossed over, see this section".
Forward references for complicated bits are fine.
i just dont want to have to rewrite everything