Stream: t-lang

Topic: many rfcs or one?


Jane Lusby (May 04 2020 at 18:00, on Zulip):

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:

Jane Lusby (May 04 2020 at 18:02, on Zulip):

so like, the return trace and move error trait to core both depend on the member access stuff

Lokathor (May 04 2020 at 18:03, on Zulip):

("An official way to do Error in core" is highly desired, but I don't have any thoughts on the RFC implications.)

Jane Lusby (May 04 2020 at 18:03, on Zulip):

I'm unsure whether I should write this as 3 rfcs or 1

Josh Triplett (May 04 2020 at 18:04, on Zulip):

There are tradeoffs.

Josh Triplett (May 04 2020 at 18:04, on Zulip):

In my opinion, I'd say "if the features can be entirely orthogonal, write separate RFCs, it'll make your life so much easier".

Jane Lusby (May 04 2020 at 18:04, on Zulip):

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

Jane Lusby (May 04 2020 at 18:05, on Zulip):

okay, yea they're definitely orthogonal, cross referencing RFCs it is

Josh Triplett (May 04 2020 at 18:05, on Zulip):

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.

Jane Lusby (May 04 2020 at 18:06, on Zulip):

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

Jane Lusby (May 04 2020 at 18:06, on Zulip):

the move the error trait to core i think entirely depends on the generic member access to be tenable

Josh Triplett (May 04 2020 at 18:07, on Zulip):

Also, first impression: :+1: to removing backtrace (yay!), :+1: to moving Error to core (depending on details).

Jane Lusby (May 04 2020 at 18:07, on Zulip):

k im gonna focus on the main one then, because that clears the way to everything else

Josh Triplett (May 04 2020 at 18:07, on Zulip):

Regarding error return traces, that one I feel interacts heavily with the concept of "context" as well.

Jane Lusby (May 04 2020 at 18:07, on Zulip):

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

Josh Triplett (May 04 2020 at 18:08, on Zulip):

I would love to have a built-in concept of "add context to an error", somehow.

Josh Triplett (May 04 2020 at 18:08, on Zulip):

Or error chaining.

Josh Triplett (May 04 2020 at 18:08, on Zulip):

Something along those lines.

Jane Lusby (May 04 2020 at 18:08, on Zulip):

well this wouldn't be tied to that

Jane Lusby (May 04 2020 at 18:08, on Zulip):

this is kinda the flip side of that feature

Josh Triplett (May 04 2020 at 18:08, on Zulip):

Well, there's one interaction.

Jane Lusby (May 04 2020 at 18:08, on Zulip):

this is how to get context out of an error

Jane Lusby (May 04 2020 at 18:09, on Zulip):

i guess the track trait is in essence the flip side

Josh Triplett (May 04 2020 at 18:09, on Zulip):

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.

Jane Lusby (May 04 2020 at 18:09, on Zulip):

of adding generic context

Jane Lusby (May 04 2020 at 18:09, on Zulip):

yea

Josh Triplett (May 04 2020 at 18:10, on Zulip):

So, for instance, today, for the first time, I wrote code that uses anyhow's 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.

Jane Lusby (May 04 2020 at 18:10, on Zulip):

``` fn downcast_refchain<T: Error + Sized + 'static>(&self) -> Option<&T>;


Jane Lusby (May 04 2020 at 18:10, on Zulip):

gdi

Lokathor (May 04 2020 at 18:10, on Zulip):

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.

Jane Lusby (May 04 2020 at 18:10, on Zulip):

is it just iterating through the sources and downcasting? @Josh Triplett

Josh Triplett (May 04 2020 at 18:11, on Zulip):

Yes, I think so.

Jane Lusby (May 04 2020 at 18:11, on Zulip):

because if so I have the same thing in my errtools crate

Jane Lusby (May 04 2020 at 18:11, on Zulip):

which is what i failed pasting above

Josh Triplett (May 04 2020 at 18:11, on Zulip):

Effectively, "if this anyhow::Error came from a std::io::Error, use that, otherwise, wrap this anyhow::Error in a std::io::Error with ErrorKind Other".

Lokathor (May 04 2020 at 18:11, on Zulip):

(I think you need a newline after the three backticks)

Jane Lusby (May 04 2020 at 18:11, on Zulip):

yea, i just always forget

Jane Lusby (May 04 2020 at 18:13, on Zulip):

i feel like a generic "add context to an error" trait would be fraught though

Jane Lusby (May 04 2020 at 18:13, on Zulip):

because presumably you'd need a default impl to ignore that info

Jane Lusby (May 04 2020 at 18:13, on Zulip):

and it would be hard to know if the error you're adding context to can even handle it

Jane Lusby (May 04 2020 at 18:13, on Zulip):

i guess if it acknowledges that it handled it

Jane Lusby (May 04 2020 at 18:13, on Zulip):

eeh, ill worry about this later as part of the Track stuff

Jane Lusby (May 04 2020 at 18:15, on Zulip):

okay but @Josh Triplett re earlier question that I think got missed

Jane Lusby (May 04 2020 at 18:15, on Zulip):

i have two possible implementations for my RFC

Jane Lusby (May 04 2020 at 18:15, on Zulip):

and theres one that i think is better because it supports DSTs but its definitely not nearly as clean looking

Jane Lusby (May 04 2020 at 18:15, on Zulip):

and i feel like it would distract from the RFC

Jane Lusby (May 04 2020 at 18:16, on Zulip):

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

Josh Triplett (May 04 2020 at 18:17, on Zulip):

I think that'll heavily confuse people.

Jane Lusby (May 04 2020 at 18:17, on Zulip):

:/

Jane Lusby (May 04 2020 at 18:17, on Zulip):

yeaaa

Josh Triplett (May 04 2020 at 18:17, on Zulip):

If you have a preferred solution, I would emphasize that, even if you have to say "some details glossed over, see this section".

Josh Triplett (May 04 2020 at 18:17, on Zulip):

Forward references for complicated bits are fine.

Jane Lusby (May 04 2020 at 18:17, on Zulip):

i just dont want to have to rewrite everything

Jane Lusby (May 04 2020 at 18:17, on Zulip):

ugh

Last update: Jun 05 2020 at 23:00UTC