Stream: project-error-handling

Topic: Blog posts


view this post on Zulip Jakub Duchniewicz (Mar 13 2021 at 09:45):

I suggest we make a thread for blog posts where we can put some error-handling related content for sharing

view this post on Zulip Jakub Duchniewicz (Mar 13 2021 at 09:45):

https://mbuffett.com/posts/rust-less-error-handling/

view this post on Zulip Jakub Duchniewicz (Mar 13 2021 at 09:45):

this one points at some rough edges, specifically the NoneError conversion problem

view this post on Zulip oliver (Mar 13 2021 at 19:16):

there are a couple of places on GH as well:
[1] https://github.com/rust-lang/project-error-handling/blob/master/advanced-error-design-patterns-book/collect-references-here
[2] https://github.com/rust-lang/project-error-handling/issues/24

view this post on Zulip oliver (Mar 13 2021 at 19:16):

depending on whether you think this should be merged into the error design patterns reference

view this post on Zulip oliver (Mar 13 2021 at 19:18):

too bad on zulip the detailed notification settings are for streams not topics as well

view this post on Zulip oliver (Mar 13 2021 at 19:38):

do you think we would have discussion here as well or just link sharing?

view this post on Zulip Jakub Duchniewicz (Mar 13 2021 at 19:45):

I think this should be a place for: "Hey, I found this blog! What do you think?" And if we come to consensus that it is valuable, then we add it as a reference material.

view this post on Zulip Jakub Duchniewicz (Mar 13 2021 at 19:45):

After all we should curate the references so that the potential reader is not overwhelmed

view this post on Zulip oliver (Mar 13 2021 at 19:51):

I think there is probably a high-volume of directly relevant content which could be examined closer

view this post on Zulip oliver (Mar 13 2021 at 19:53):

in college I joined a informal research reading-group which was a spare-time effort to connect and read together

view this post on Zulip oliver (Mar 13 2021 at 19:55):

it wasn't the easiest to coordinate since everyone was busy and the outcomes weren't tangible

view this post on Zulip oliver (Mar 13 2021 at 19:57):

I'm generally keen for anything related to a rust reading group

view this post on Zulip oliver (Mar 13 2021 at 20:01):

oliver said:

it wasn't the easiest to coordinate since everyone was busy and the outcomes weren't tangible

what I mean is that it's the kind of thing that benefits the relative beginner more than the experts

view this post on Zulip oliver (Mar 13 2021 at 20:02):

so it wasn't too hard to get a group of peers together but including an instructor or even a TA was challenging

view this post on Zulip Jakub Duchniewicz (Mar 13 2021 at 20:05):

I think we could do a biweekly reading group meeting, for starters

view this post on Zulip Jakub Duchniewicz (Mar 13 2021 at 20:06):

choosing a person in charge would be difficult though

view this post on Zulip Jakub Duchniewicz (Mar 13 2021 at 20:06):

taking into account that we are already writing a book on the topic

view this post on Zulip oliver (Mar 13 2021 at 20:11):

I think before or after the existing Thursday BoF might be appropriate/convenient

view this post on Zulip oliver (Mar 13 2021 at 20:20):

what I envision is taking turns live reading a article(s) with pauses for questions or observations

view this post on Zulip oliver (Mar 13 2021 at 20:22):

maybe someone taking notes if something comes out of that, so it can be ideally light on administration

view this post on Zulip Jakub Duchniewicz (Mar 13 2021 at 20:42):

some of them might be quite lengthy

view this post on Zulip Jakub Duchniewicz (Mar 13 2021 at 20:43):

but I don't know a good alternative to reading in turns rn

view this post on Zulip oliver (Mar 13 2021 at 20:44):

there are services where you can markup webpages and share notes

view this post on Zulip Jane Lusby (Mar 16 2021 at 00:01):

oliver said:

I think before or after the existing Thursday BoF might be appropriate/convenient

I'm down, do you want to run this @oliver ?

view this post on Zulip oliver (Mar 16 2021 at 02:11):

ok, let's plan to say longer after the regular BoF for a study session!

view this post on Zulip Jakub Duchniewicz (Mar 23 2021 at 08:23):

Quote from Zig's reasoning

If a language makes it too easy to ignore errors, and thus to verify that a library correctly handles and bubbles up errors, it can be tempting to ignore the library and re-implement it, knowing that one handled all the relevant errors correctly. Zig is designed such that the laziest thing a programmer can do is handle errors correctly, and thus one can be reasonably confident that a library will properly bubble errors up.

view this post on Zulip Jakub Duchniewicz (Mar 23 2021 at 08:24):

Not familiar with the language itself, but the philosophy appeals to me, and that is what we should strive for IMO

view this post on Zulip Jakub Duchniewicz (Mar 23 2021 at 08:25):

Laziest way -> best way

view this post on Zulip oliver (Mar 23 2021 at 14:39):

Here was some commentary along these lines:
https://users.rust-lang.org/t/why-arent-some-basic-traits-automatically-derived/57311/10

view this post on Zulip Jane Lusby (Mar 23 2021 at 18:46):

I might have to re review their error handling but last time I checked I was not impressed by zigs approach

view this post on Zulip Jane Lusby (Mar 23 2021 at 18:46):

It's basically a global enum of errors

view this post on Zulip Jane Lusby (Mar 23 2021 at 18:47):

And as far as I know doesn't allow for composition

view this post on Zulip Jane Lusby (Mar 23 2021 at 18:47):

So if you want to have an error cause a new error you have to create a new variant that represents the new error and it's cause

view this post on Zulip Jane Lusby (Mar 23 2021 at 18:48):

Which restricts how you can report errors and what errors you can model

view this post on Zulip Jane Lusby (Mar 23 2021 at 18:48):

I do like that it makes it easier in the basic case

view this post on Zulip Jane Lusby (Mar 23 2021 at 18:48):

But I'm not convinced the tradeoff is worth it

view this post on Zulip oliver (Mar 23 2021 at 19:19):

aren't we saying that the large error structs are anti-patterns in Rust

view this post on Zulip Jane Lusby (Mar 24 2021 at 00:12):

no, we're just saying that large error types, as in large size_of::<T>(), are a foot gun to be wary of

view this post on Zulip Jane Lusby (Mar 24 2021 at 00:12):

but the solution of this isn't to avoid error composition

view this post on Zulip Jane Lusby (Mar 24 2021 at 00:13):

its just to be wary and mindful of when to start allocating errors or audit which pieces of context are necessary, usually in response to benchmarks

view this post on Zulip Jane Lusby (Mar 24 2021 at 00:13):

this is like, a microoptimization in most cases


Last updated: Jan 26 2022 at 13:21 UTC