Stream: project-error-handling

Topic: Meeting 09-28-2020


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

Meeting thread

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

here are the minutes and the agenda for todays meeting https://hackmd.io/th5k9_pBRBGmpgnFWJzUHw?both

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

So I think the best place to start is probably with the first issue on the agenda, stabilizing Backtrace and moving std::error::Error to core

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

let me pull up the issue on it so ppl can get background

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

https://github.com/rust-lang/project-error-handling/issues/3

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

so to gist where this issue currently is, we need to prototype a solution for exposing Backtrace as a type in core with the interface it currently provides in std

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

and I think the biggest question right now is

should we do a trait object based solution internally with an unstable Backtrace trait in core and a stable Backtrace type in core or should we use global hooks like panic_impl

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

the bottom of the issue has some analysis of the tradeoffs

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

https://github.com/rust-lang/project-error-handling/issues/3#issuecomment-699525989

view this post on Zulip oliver (Sep 28 2020 at 18:06):

You favor global hooks?

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

I haven't really made up my mind personally

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

global hooks look like more work to use, and then if we do go that route theres questions about how that should be accomplished

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

because the existing global hooks are all kinda ad-hoc and magical in different ways

view this post on Zulip oliver (Sep 28 2020 at 18:07):

Does asking for a prototype generally mean producing an RFC?

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

but I can't think of any reason why we'd want to be able to support multiple types of Backtraces being represented via the core::backtrace::Backtrace type

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

I don't think we need an RFC at this stage

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

tho we might need one to merge the changes

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

but the main goal of the prototype is to prove we won't back ourselves into a corner if we stabilize fn backtrace on Error

view this post on Zulip Lokathor (Sep 28 2020 at 18:08):

avoiding more global hooks is probably good. if the point is getting it into core, that's one more thing that every no_std user would potentially have to worry about even if they don't use backtracing.

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

ah yea thats another thing

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

so I don't think we should expose the need to implement those hooks to no_std users

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

like with #[panic_handler]

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

so we'd need to provide a default implementation of those hooks in no_std

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

and I don't know of any examples of that already

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

so that might be new features we have to add to the compiler

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

the advantage of the hooks though is that they're going to optimize better

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

because there is no virtual function calls

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

and I don't think that virtual function calls are really justified for the Backtrace type

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

which is what makes me feel like hooks might be the right solution, tho I think the language needs better support for these kinds of hooks

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

i made a t-lang thread about it

view this post on Zulip Ashley Mannix (Sep 28 2020 at 18:10):

Backtraces aren’t typically on the hot path though, right?

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

https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/global.20hooks.20and.20their.20relation.20to.20traits.20and.20vtables/near/211372160

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

thats true @Ashley Mannix

view this post on Zulip Lokathor (Sep 28 2020 at 18:10):

yeah they're usually on the "i'm about to kill this thread" path

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

tho if you put the backtrace on the stack it would increase the size of your errors

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

because the Backtrace type would be two words instead of one presumably

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

and that could affect the happy path

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

if it grows the size of your Results and therefore your stack frames

view this post on Zulip Lokathor (Sep 28 2020 at 18:11):

if you keep it to two words or less you can usually stay happy, but that'd for like the full Result<T,E>

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

that could be fixed with more indirection though

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

if we wanted to put it behind a second Box

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

but then actually

view this post on Zulip Ashley Mannix (Sep 28 2020 at 18:12):

Hmm, yeh I was going to say I think the usual solution to that is to box it all up :thinking:

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

core wouldn't be able to put a second box there probably

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

i guess maybe with BoxMeUp

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

so yea this is where I'm stuck right now

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

not sure what choice to make

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

:/

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

@Ashley Mannix @Lokathor it sounds like yall think a Trait based solution would be fine

view this post on Zulip Lokathor (Sep 28 2020 at 18:14):

In core, what i'd want myself.. so i use core for making GBA games, and the emulator i test in has a fake output stream a game can use. So what I'd want as a user is a way to have some sort of backtrace that i immediately point at the output stream and get formatted to there. And I otherwise never want to pass it around or keep it in any way.

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

really wishes boats was participating because they did the legwork on the backtrace issue and seemed opposed to the trait based solutions

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

@Lokathor so you'd never use the fn backtrace method on the error trait probably?

view this post on Zulip Ashley Mannix (Sep 28 2020 at 18:16):

It sounds like the trait-based approach has fewer magic compiler pieces and so could be easier to put together?

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

Ashley Mannix said:

It sounds like the trait-based approach has fewer magic compiler pieces and so could be easier to put together?

I believe so, yes

view this post on Zulip Ashley Mannix (Sep 28 2020 at 18:17):

Could we imagine anybody besides std wanting to provide the capturing implementation?

view this post on Zulip Lokathor (Sep 28 2020 at 18:18):

@Jane Lusby yeah for core I think that you'd probably want something more like write_backtrace_to(&mut dyn FormatterThing) -> Result<(),FormatterThing::Error>

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

in a general sense yes definitely, tho I don't think we have any concrete reason why they'd need to be able to have that implementation be the backing for core::backtrace::Backtrace rather than their own new type

view this post on Zulip Lokathor (Sep 28 2020 at 18:18):

that's if that would help avoid the boxing difficulty and make it simpler to design

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

but theres tracing::SpanTrace which is essentially a Backtrace

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

and I've also seen ppl interested in backtraces that capture wasm / python frames

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

Lokathor said:

Jane Lusby yeah for core I think that you'd probably want something more like write_backtrace_to(&mut dyn FormatterThing) -> Result<(),FormatterThing::Error>

that might be a good API to eventually propose on Backtrace

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

maybe as an inherent function with no self parameter

view this post on Zulip Lokathor (Sep 28 2020 at 18:19):

Yeah I can think of a few folks from the Community Discord who would want to capture a backtrace outside of std

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

for me tho I think those ppls needs will already be met by https://github.com/rust-lang/rfcs/pull/2895

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

which I wrote so I could integrate SpanTrace with the error trait

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

as long as you have a way to access the different types of backtraces from dyn Error objects I see no reason why they'd need to integrate with the core::backtrace::Backtrace type

view this post on Zulip BatmanAoD (Kyle Strand) (Sep 28 2020 at 18:21):

It does seem that inherent functions avoid Boats' concern in the linked comment.

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

and in particular you said no_std ppl are more interested in formatting backtraces immediately than they are in carrying them around in Error types and later accessing them from type erased objects

view this post on Zulip Lokathor (Sep 28 2020 at 18:22):

Was it backtracing which brought up the "we might need to merge core/alloc/std into a single crate sooner than expected" subject i recall from the other day?

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

BatmanAoD (Kyle Strand) said:

It does seem that inherent functions avoid Boats' concern in the linked comment.

inherent functions as in the direct fmting stuff @Lokathor is talking about?

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

kinda @Lokathor

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

this backtrace discussion is ultimately about moving Error to core

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

and there are other issues that are already present that we have to deal with

view this post on Zulip BatmanAoD (Kyle Strand) (Sep 28 2020 at 18:22):

Yes, though Boats' specific example was indexing on frames.

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

and I think solving those requires merging core and std

view this post on Zulip Lokathor (Sep 28 2020 at 18:23):

core::io when :/

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

but we still want to be able to use the Error trait when we compile std with no-alloc

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

so the Backtrace interface still needs to be something that is completely compatible with the current core

view this post on Zulip Lokathor (Sep 28 2020 at 18:23):

ah, so no matter what we need a non-allocating Error

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

yea

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

making a core::io::Error is going to be real hard for that same reason
t

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

that would be one hell of a hacky error type

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

not convinced it really can be done

view this post on Zulip Lokathor (Sep 28 2020 at 18:24):

i suspect it'd wrap an error code u32 newtype

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

definitely down to try later tho once we've sorted the error trait stuff

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

it has a variant that stores a Box<dyn Error>

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

or maybe it doesnt...

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

checking

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

https://doc.rust-lang.org/stable/src/std/io/error.rs.html#67-71

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

enum Repr {
    Os(i32),
    Simple(ErrorKind),
    Custom(Box<Custom>),
}

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

yuuup

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

sad days

view this post on Zulip Lokathor (Sep 28 2020 at 18:26):

As i've found myself saying lately, "yay"

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

struct Custom {
    kind: ErrorKind,
    error: Box<dyn error::Error + Send + Sync>,
}

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

boxes boxes boxes boxes

view this post on Zulip Lokathor (Sep 28 2020 at 18:26):

That's all so very unfortunate. But also, fixable

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

oo

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

glad you think so

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

but I think this is getting off topic a bit for now

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

fixing io::Error has to come second so lets focus on the backtrace and trait

view this post on Zulip Lokathor (Sep 28 2020 at 18:27):

in core, instead of a box, you just get a usize, and whatever you want to do with a usize is up to you.

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

so it sounds like we think it would be best to just do a trait based impl for Backtrace in core?

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

cc @Ashley Mannix

view this post on Zulip Lokathor (Sep 28 2020 at 18:28):

seems that way

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

if yes then I'll plan on doing that impl as the next step

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

oh this isn't on the agenda but its something I wanted to ask

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

@Ashley Mannix should I be escalating issues from these meetings / this group to libs team meetings?

view this post on Zulip Ashley Mannix (Sep 28 2020 at 18:29):

@Jane Lusby That’s the private trait + public newtype wrapper?

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

yea

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

it has to be a public trait I think

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

pub but unstable

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

then std would unstably implement it

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

wait

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

how would core then construct that?

view this post on Zulip oliver (Sep 28 2020 at 18:30):

So the newtype is the reporter?

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

not sure I'd use that term but sorta?

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

its like the interface that isn't subject to coherence rules

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

so we can add new methods without having to worry about breaking changes to downstream ppl who implemented the trait

view this post on Zulip Jakub Duchniewicz (Sep 28 2020 at 18:31):

Just for clarification: the main reason why backtrace hooks are worse solution than a Backtrace type in core is because it is more work for the compiler team?

view this post on Zulip Ashley Mannix (Sep 28 2020 at 18:31):

I think @eddyb had an example of building it that appeared to work

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

as opposed to having the error trait interface be fn backtrace(&self) -> Option<&dyn Backtrace>

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

aah yes

view this post on Zulip Lokathor (Sep 28 2020 at 18:32):

@Jakub Duchniewicz and potentially more work for every single user too

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

so that does involve 1 hook still I think

view this post on Zulip Jubilee (Sep 28 2020 at 18:32):

mentioned ages ago but: there are plenty of prototype implementations that were deemed valuable enough to try a quick round at implementing and see how things go, in the compiler, before accepting the RFC. This is why the MCProcess also exists.

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

hmm
i guess the question is "do we want lots of hooks or few"

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

Jubilee said:

mentioned ages ago but: there are plenty of prototype implementations that were deemed valuable enough to try a quick round at implementing and see how things go, in the compiler, before accepting the RFC. This is why the MCProcess also exists.

I didn't know that

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

we should definitely try to find those impls

view this post on Zulip Jubilee (Sep 28 2020 at 18:33):

I mean in general regarding like, concepts, not necessarily specifically this.

view this post on Zulip Lokathor (Sep 28 2020 at 18:33):

(Yeah, never doing any work before an RFC is actually not the best way to discover good design, it turns out)

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

Lokathor said:

Jakub Duchniewicz and potentially more work for every single user too

I think this is only the case if we ever let users implement these hooks

view this post on Zulip Jubilee (Sep 28 2020 at 18:33):

For instance, the Lazy types RFC.

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

which I expect to be years away

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

okay well I think we basically have a resolution

view this post on Zulip oliver (Sep 28 2020 at 18:34):

@Jane Lusby you spent some time trying to figure out how panic hooks are configured in core?

view this post on Zulip Lokathor (Sep 28 2020 at 18:34):

If core had an automatic hook, and it wasn't always removed by optimizations when unused, you'd spark a riot with the embedded people.

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

we need to do the impl, we will start with eddyb's impl and see how many hooks end up still being necessary

view this post on Zulip Lokathor (Sep 28 2020 at 18:34):

next agenda item?

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

Lokathor said:

If core had an automatic hook, and it wasn't always removed by optimizations when unused, you'd spark a riot with the embedded people.

I'll add this to the checklist of things to make sure we've verified for any proof of concept

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

okay so next

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

what RFCs should we be tracking and following up on?

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

so far I've added the backtrace RFC and the generic member access one I wrote

view this post on Zulip oliver (Sep 28 2020 at 18:35):

#2895

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

I think we area also tracking one related to linux error codes though

view this post on Zulip oliver (Sep 28 2020 at 18:36):

#2504

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

@Oliver is that the right issue number?

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

the first one

view this post on Zulip oliver (Sep 28 2020 at 18:36):

Maybe not

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

yea these are all linking to old rust-lang issues

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

lol

view this post on Zulip oliver (Sep 28 2020 at 18:36):

https://github.com/yaahc/rfcs/blob/master/text/0000-dyn-error-generic-member-access.md

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

yup, so we got that one already

view this post on Zulip Lokathor (Sep 28 2020 at 18:36):

https://github.com/rust-lang/rfcs/pull/2895 right issue, wrong repo

view this post on Zulip Ashley Mannix (Sep 28 2020 at 18:37):

On the Libs project board we have 7 things with the error-handling tag: https://github.com/rust-lang/libs-team/projects/2#column-10224181

view this post on Zulip oliver (Sep 28 2020 at 18:37):

https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md

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

aah fantastic

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

now I'm wondering if it makes sense for us to have our own project board

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

or if we shoudl just focus on the libs team board

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

i set this up earlier

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

https://github.com/rust-lang/project-error-handling/projects/1

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

its a bit more details because it has multiple columns related to error handling

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

but im not sure thats worth the cost of duplication

view this post on Zulip Sean Chen (he/him) (Sep 28 2020 at 18:39):

I'd like our own separate board, partly so it's clearer which ones we're just focusing on.

view this post on Zulip Lokathor (Sep 28 2020 at 18:39):

the simd project group is likely to remove our own duplications in the next few days. it's just a hastle

view this post on Zulip Sean Chen (he/him) (Sep 28 2020 at 18:39):

I don't follow what the libs team is doing :innocent:

view this post on Zulip Ashley Mannix (Sep 28 2020 at 18:39):

I think having a way to track status in a more fine-grained way might be worthwhile. The Libs board is intentionally not really status-focused

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

lets try keeping ours as well, and we can put a link to the libs team board in our project description

view this post on Zulip Ashley Mannix (Sep 28 2020 at 18:40):

Besides its use of status labels :smile:

view this post on Zulip DPC (Sep 28 2020 at 18:40):

can take care of that :stuck_out_tongue:

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

digging into this further

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

I'd love to get volunteers for each of these tracking issues to be people who are focused on resolving them

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

for example https://github.com/rust-lang/rust/issues/58520

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

I don't know what is holding this one up but I expect its not much

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

and I think it would be a good issue for just about any skill level

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

looks like its had some movement 2 weeks ago

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

maybe we should just make that part of the meeting agenda

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

status report on tracked issues

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

alright lets do that, and then when we identify stalled issues we can pick those up

view this post on Zulip Charles Ellis O'Riley Jr. (Sep 28 2020 at 18:43):

If it's any skill level, I'll take a stab at it but I antiscipate I'll need some assistance.

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

it seems like there's a lot to dig into here

view this post on Zulip oliver (Sep 28 2020 at 18:43):

It'll need some study

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

so lets not do that today, we can prep status reports on tracking issues for our next meeting

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

ill get volunteers or do the study myself before the next meeting

view this post on Zulip Charles Ellis O'Riley Jr. (Sep 28 2020 at 18:44):

k

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

so lets move onto the next agenda item

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

15 minutes left

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

Planning for "Communicating best practices"

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

So I think this basically boils down to we should setup an error handling group and start filling it out

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

I don't want to call it "The Book of Error" though because I'm worried that that may have not great overlap with "The Book of Mormon"

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

"The Error Book" is what I'd go with

view this post on Zulip Sean Chen (he/him) (Sep 28 2020 at 18:45):

Jane Lusby said:

I don't want to call it "The Book of Error" though because I'm worried that that may have not great overlap with "The Book of Mormon"

I thought that was the joke

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

i think it was, I just wanted to make sure the joke doesn't become reality

view this post on Zulip oliver (Sep 28 2020 at 18:46):

"A Cargo Cultists Guide to Error Handling" <- keeping it spiritual :P

view this post on Zulip must-compute (Sep 28 2020 at 18:46):

I think adding Rust to the book title will help with search results
The Rust Error Book

view this post on Zulip Sean Chen (he/him) (Sep 28 2020 at 18:46):

Are we for sure going with writing a book? Are there any other options on the table?

view this post on Zulip Charles Ellis O'Riley Jr. (Sep 28 2020 at 18:46):

Error Handling In Rust?

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

I haven't heard other proposals @Sean Chen

view this post on Zulip oliver (Sep 28 2020 at 18:47):

Book <--> Documentation

view this post on Zulip must-compute (Sep 28 2020 at 18:47):

The book can be a detailed guide sort of thing, like the Rust CLI Book

view this post on Zulip oliver (Sep 28 2020 at 18:47):

pretty interchangeable to me

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

I expect there will be quite a few different sections with different focuses

view this post on Zulip Charles Ellis O'Riley Jr. (Sep 28 2020 at 18:47):

How about making it as user friendly as possible?

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

we probably want to come up with some guidance on FFI error handling

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

because I've seen that as a repeat pain point that gets neglected a lot

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

Charles Ellis O'Riley Jr. said:

How about making it as user friendly as possible?

absolutely a goal

view this post on Zulip DPC (Sep 28 2020 at 18:48):

i titled it "Book of Error" as a pun on pain points of original error handling in rust :stuck_out_tongue:

view this post on Zulip Lokathor (Sep 28 2020 at 18:48):

Book<Error>

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

DPC said:

i titled it "Book of Error" as a pun on pain points of original error handling in rust :P

aah, I see

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

lol @Lokathor

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

but does anyone have any alternate suggestions ?

view this post on Zulip Lokathor (Sep 28 2020 at 18:49):

So i presume we're talking about an mdbook "book"?

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

or do we all think just add a book section to the project repo and start filling it out?

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

yes @Lokathor

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

alrighty

view this post on Zulip Lokathor (Sep 28 2020 at 18:49):

yeah, mdbook on github pages is what rust users expect

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

so the last agenda item I don't think we have time to fully discuss today

view this post on Zulip DPC (Sep 28 2020 at 18:49):

ye let's carry it forward

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

so I'm not sure if we should get into it but lets go

view this post on Zulip Lokathor (Sep 28 2020 at 18:50):

we got 10 minutes i bet we can at least say something

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

How users expect error handling to be, As in, we take a leap into the future and assume all this was implemented into the language, then how it would potentially look

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

so this is essentially "what is our vision for the future of error handling"

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

and I have a pretty strong idea for where I want to see things go

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

I'd like to see error in core and the various interfaces that are unstable stabilized

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

I'd like an iterator API on backtrace

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

I want generic member access, possibly with a two way flow of information possible

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

I want to see error return traces

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

which would probably rely upon the generic member access features

view this post on Zulip Charles Ellis O'Riley Jr. (Sep 28 2020 at 18:51):

The best way to write code to implement possible errors in Rust?

view this post on Zulip Sean Chen (he/him) (Sep 28 2020 at 18:51):

This whole topic sounds like it's ripe to be published and communicated via a blog post or something.

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

I want to find some way to universally hook into all error reporting points for consistent error reporting across full applicatoins

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

so if you panic explicitly, via an unwrap, or report an error, it always uses the correct report format and preserves all context

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

I don't personally think its important that we get an error derive or a reporting type in std any time soon honestly

view this post on Zulip Lokathor (Sep 28 2020 at 18:52):

I'd like to see better handling of error enums, and then merging the error enum cases as you move up the call stack. Simply grabbing all the error info without the program reacting and moving forward in at least some of the potential error cases always seems poor.

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

I don't think that space has been explored well enough still

view this post on Zulip BatmanAoD (Kyle Strand) (Sep 28 2020 at 18:53):

What about ways of recovering from recoverable errors? That seems to me like a pretty wide-open unaddressed area of concern.

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

BatmanAoD (Kyle Strand) said:

What about ways of recovering from recoverable errors? That seems to me like a pretty wide-open unaddressed area of concern.

what do you mean?

view this post on Zulip Lokathor (Sep 28 2020 at 18:54):

that's sorts what my error enums comment was about

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

I'd think that match and downcast pretty thoroughly cover reacting (to recover) to recoverable errors

view this post on Zulip Lokathor (Sep 28 2020 at 18:55):

well one thing is that the best code to react to an error doesn't always exist at the error's level.

view this post on Zulip BatmanAoD (Kyle Strand) (Sep 28 2020 at 18:55):

Right

view this post on Zulip DPC (Sep 28 2020 at 18:55):

_5 mins remaining_

view this post on Zulip Lokathor (Sep 28 2020 at 18:55):

if the user opens a PNG, and it's corrupted, the PNG parser doesn't know how to open a message box to ask the users to continue anyway or not

view this post on Zulip BatmanAoD (Kyle Strand) (Sep 28 2020 at 18:55):

And I agree the enum-convergence as errors propogate up-stack is related

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

I'd want to see us publish an The Rust Error Book, and I'd like to see us potentially contribute to The Book to make its error handling recommendations consistent with our final recommendations

view this post on Zulip Jubilee (Sep 28 2020 at 18:56):

Wouldn't it make sense to propagate that error, then?

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

Lokathor said:

if the user opens a PNG, and it's corrupted, the PNG parser doesn't know how to open a message box to ask the users to continue anyway or not

can you create an issue for this? seems like it might be a good discussion topic to track

view this post on Zulip Lokathor (Sep 28 2020 at 18:56):

uh, sure

view this post on Zulip Jubilee (Sep 28 2020 at 18:56):

re: multiple repos, aside: it makes less sense for Portable SIMD to have a project repo because we have a stdsimd repo as well.

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

thats all I can think of for now

view this post on Zulip DPC (Sep 28 2020 at 18:58):

before we conclude and since we have 3 mins, do we have "action points" -> things people want to work on before the next meeting?

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

yea, I think it would be great if we could get ppl to follow up and summarize the current issues we're tracking

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

I'm going to be focusing on the proof of concept for core Backtrace

view this post on Zulip Lokathor (Sep 28 2020 at 18:58):

"start the mdbook" seems like something that could be done in 1 week, even if it's just TOC and CI setup

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

good point

view this post on Zulip DPC (Sep 28 2020 at 18:59):

mdbook takes lesser time to setup :stuck_out_tongue:

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

any volunteers?

view this post on Zulip must-compute (Sep 28 2020 at 18:59):

I can dedicate a lot of time to the book

view this post on Zulip Charles Ellis O'Riley Jr. (Sep 28 2020 at 19:00):

I'll take a stab. Where shouldit be placed.

view this post on Zulip Jane Lusby (Sep 28 2020 at 19:00):

in the project-error-handling repo

view this post on Zulip Jane Lusby (Sep 28 2020 at 19:00):

let me find an example you can base things off of

view this post on Zulip DPC (Sep 28 2020 at 19:00):

you can follow the rust cli book

view this post on Zulip Charles Ellis O'Riley Jr. (Sep 28 2020 at 19:00):

:+1:

view this post on Zulip Jane Lusby (Sep 28 2020 at 19:01):

also wg-traits https://github.com/rust-lang/wg-traits

view this post on Zulip Jane Lusby (Sep 28 2020 at 19:01):

I know they have the CI all setup already

view this post on Zulip Jane Lusby (Sep 28 2020 at 19:01):

alright we're over time

view this post on Zulip Jane Lusby (Sep 28 2020 at 19:02):

thanks everyone for coming!

view this post on Zulip Jane Lusby (Sep 28 2020 at 19:02):

and ty @Sean Chen for taking the minutes

view this post on Zulip Jane Lusby (Sep 28 2020 at 19:02):

next meeting is same time 2 weeks from now

view this post on Zulip Jakub Duchniewicz (Sep 28 2020 at 19:02):

I can help with CI stuff via GH Actions

view this post on Zulip Jakub Duchniewicz (Sep 28 2020 at 19:02):

@Charles Ellis O'Riley Jr.

view this post on Zulip Jane Lusby (Sep 28 2020 at 19:02):

I'll create the agenda thread right away so people can propose agenda items as they think of things

view this post on Zulip Jane Lusby (Sep 28 2020 at 19:02):

have a good day everyone and stay safe

view this post on Zulip Charles Ellis O'Riley Jr. (Sep 28 2020 at 19:03):

Cool @Jakub Duchniewicz

view this post on Zulip DPC (Sep 28 2020 at 19:03):

next meeting is at the same time in 2 weeks

view this post on Zulip DPC (Sep 28 2020 at 19:04):

view this post on Zulip nagisa (Sep 28 2020 at 22:23):

a nasty consequence of global hooks is also that they must be globally unique

view this post on Zulip nagisa (Sep 28 2020 at 22:23):

e.g. you cannot just build a codebase that in crate graph has crates that require both abort and unwind panicking mechanism

view this post on Zulip Jane Lusby (Sep 28 2020 at 22:24):

nagisa said:

a nasty consequence of global hooks is also that they must be globally unique

yea

view this post on Zulip Jane Lusby (Sep 28 2020 at 22:24):

you gotta be really sure that you're only ever going to need one implementation of that functionality in any binary if you want to use global hooks

view this post on Zulip nagisa (Sep 28 2020 at 22:25):

well, the solution in this situation is to only trust the final artifact (i.e. non-library crate) to specify the global hooks

view this post on Zulip nagisa (Sep 28 2020 at 22:26):

been working well enough so far, it just leaves a bad aftertaste

view this post on Zulip Josh Triplett (Sep 30 2020 at 21:14):

Global hook-types based on traits came up in today's lang design meeting. Generally speaking, people seemed in favor, modulo implementation details (which were considerable).

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

seems like a pretty restricted scope project group might be in order then?


Last updated: Jan 26 2022 at 14:20 UTC