Stream: project-error-handling

Topic: The Book of Error


view this post on Zulip oliver (Sep 21 2020 at 15:31):

Early impression of the teams and working groups is that GH issues and PRs get a
lot of traction and shares which OFC is always appreciated but it's still
sometimes a pretty big data dump loaded with background info and links. Maybe we
would start by defining and including some of our key terms in the rustc docs
glossary and drafting a shared bibliography and tl;dr notes?

view this post on Zulip oliver (Sep 21 2020 at 15:34):

That is pretty much reflected here:
https://github.com/rust-lang/project-error-handling/blob/master/CHARTER.md

view this post on Zulip oliver (Sep 21 2020 at 15:38):

Something like this: https://github.com/rust-lang/wg-async-foundations/tree/master/src

view this post on Zulip Jane Lusby (Sep 21 2020 at 16:49):

I was thinking we might want to start by creating an error handling book that is stored in our project group repo and use that to develop things like a glossary of terms and chapters on discussion topics such as "API Stability". We can probably build a lot off of the "Failure Book".

view this post on Zulip oliver (Sep 21 2020 at 18:08):

An error handling book would be incredible!

view this post on Zulip oliver (Sep 21 2020 at 18:11):

Which is the Failure Book?

view this post on Zulip oliver (Sep 21 2020 at 18:12):

https://boats.gitlab.io/failure/

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

that's the one

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

another section that I think would be useful would be some api guidelines, specifically so we can explain how to write "idiomatic error messages", tho im not sure that will be something that we can actually define

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

but its worth looking into i think

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

i have my own conventions that I follow that I've tried to base on the conventions in std, I'd be very interested to hear everyone else's conventions

view this post on Zulip DPC (Sep 21 2020 at 20:01):

(renamed this as "The Book of Error" :stuck_out_tongue: )

view this post on Zulip DPC (Sep 21 2020 at 20:01):

i like the idea of the book, I often come across people asking "how to handle errors" and related questions, and it would be nice to point them towards a official resource

view this post on Zulip Jane Lusby (Sep 21 2020 at 20:02):

agreed

view this post on Zulip Jubilee (Sep 21 2020 at 20:03):

it doesn't have to be about "idiomatic error messages", it can be a checklist of "have you thought about this?"

view this post on Zulip Jake Goulding (Sep 21 2020 at 20:03):

I'd like it to have a chapter that is just titled "There's no One True Way".

view this post on Zulip Jane Lusby (Sep 21 2020 at 20:03):

_wondering how the Rust API Guidelines word this_

view this post on Zulip Jane Lusby (Sep 21 2020 at 20:04):

they call it guidelines

view this post on Zulip Jane Lusby (Sep 21 2020 at 20:04):

and they have a checklist

view this post on Zulip Jane Lusby (Sep 21 2020 at 20:04):

whatever we do we should follow the example set here https://rust-lang.github.io/api-guidelines for any guidelines we come up with

view this post on Zulip Jubilee (Sep 21 2020 at 20:05):

Error types are meaningful and well-behaved (C-GOOD-ERR)

view this post on Zulip Jake Goulding (Sep 21 2020 at 20:06):

view this post on Zulip Jake Goulding (Sep 21 2020 at 20:07):

My feels are that there should be "here's ways of doing things. Here's pros/cons. If you still don't know what you want, start with this"

view this post on Zulip Jake Goulding (Sep 21 2020 at 20:08):

but i understand that people prefer to not be forced to think or design and just want The Answer.

view this post on Zulip Jake Goulding (Sep 21 2020 at 20:10):

(I've heard that phrased as a downside to Rust in general: "I don't like Rust because it makes you think about what you are trying to do before you do it").

view this post on Zulip oliver (Sep 21 2020 at 20:20):

It's entirely conceivable that error handling could be (or is already) good enough
in Rust to convert generally negative views like that into overall positive
sentiment.

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

My experience begs to differ

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

my personal feeling is that there's only so much we can do, and there will always be a subset of the rust community who is vocal about disliking how "complicated" error handling is in rust

view this post on Zulip Jake Goulding (Sep 21 2020 at 20:23):

Amusingly, I also heard some of the opposite:

It's just I completely fail to understand what the fuss is all about when it comes to error handling. I don't understand the existence of the myriad error handling libraries, nor the vast amount of improvement ideas, which are in my book introduce zero improvements to the language.
I think Rust has an incredibly nice, convenient, consistent, and simple (!) way of dealing with errors, without magic and whatnot. It just works and it does an amazing job -- by far the best I've seen in the dozen or so languages I speak. I'm not against improvements in general, for example I like the idea of the try-blocks as it was discussed earlier this year. But to create a work-group around this and invest precious time into a non-existent problem.. I fail to see how that's useful.

view this post on Zulip Jane Lusby (Sep 21 2020 at 20:24):

:grimacing:

view this post on Zulip Jane Lusby (Sep 21 2020 at 20:25):

seems like the difference between "I know how I like to handle errors and I have no interest in learning more about it" and "I dont know how to handle errors and I have no interest in learning more about it"

view this post on Zulip Jane Lusby (Sep 21 2020 at 20:26):

alternatively you could view it as a split between "rust error handling is overcomplicated" and "3rd party error handling libraries are overcomplicated"

view this post on Zulip oliver (Sep 21 2020 at 20:32):

Which languages are considered to have a comparable error system?

view this post on Zulip oliver (Sep 21 2020 at 20:32):

Off the top of my head I can't think of a decent competitor

view this post on Zulip DPC (Sep 21 2020 at 20:34):

the problem is everyone wants a different way of error handling and wants that way to be the way :stuck_out_tongue:

view this post on Zulip Jubilee (Sep 21 2020 at 20:36):

Lots of people just want the textual simplicity of Python when writing Rust, and the answer to them is basically always going to be "no, you don't get that." and then a pause, and adding, "but maybe we can get closer."

view this post on Zulip Jubilee (Sep 21 2020 at 20:46):

cf. the recent proposal for a short-hand prompt API (good! the current machinery is kinda bulky!) which went all the way up to suggesting, explicitly, "it should be one line because the Python API is one line."

view this post on Zulip oliver (Sep 21 2020 at 20:56):

One-liners can turn pretty evil honestly

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

Even what you want to do on an error matters. If you want to handle some error cases, you generally need an error enum because that's how rust handles variant situations. If you don't want to handle errors and you just want to say there was an error then Box<dyn ErrorTrait> is all you really need... unless you're no_alloc in which case it's back to the error enum (or even just integer codes, gross) for you.

view this post on Zulip Seán Kelleher (Sep 22 2020 at 07:36):

I think a lot of people just don't want to deal with errors at all, e.g. just want to throw unchecked exceptions and forget about them, and handle them in a single try block at the top level. A lot of error "handling" seems to boil down to just logging that a problem occurred. I think for a lot of people, error handling just isn't the "fun" part of programming, and so they don't want to spend more time on it. That's just my opinion, anyway.

view this post on Zulip Seán Kelleher (Sep 22 2020 at 07:44):

I agree with Jake, that the book should probably describe the different "main" ways of error handling, so that at the very least there's some convention when people decide how they perform error handling, even if they do it in a custom way. Just as a suggestion, I think it should start by laying out a basic/fairly hands-off approach, because realistically, this is going to be the go-to for those people who want quick answers, I'm guessing. This will probably boil down to using ? to throw errors that come from an Error enum with all of your variants, define reporters on the variants, and when you run into a problem where you need more context, this is how you add that context. This should be enough to help such people get off the ground and forget about errors. Then there could be one or two more chapters that detail extra "layers" of error handling, depending on how rigorous you want it. These could do things like introduce SNAFU, recommend adding all relevant context for each error, overview of Backtrace etc.

view this post on Zulip Seán Kelleher (Sep 22 2020 at 07:46):

Another suggestion is that it should hopefully be referenced, or perhaps integrated somewhat, in the Rust book; I tend to go to that as a de-facto guide on conventions, etc., and I wonder if others do too.

view this post on Zulip imbolc (Sep 23 2020 at 07:54):

I'd like the book to have a few entry points, e.g. "coming from c-like langs", "from exception-based langs", "rust as a new lang". And also a chapter on gradual error development, so it would describe how to lay an extendable foundation for error handling with minimal initial effort.

view this post on Zulip Mukund Lakshman (Sep 23 2020 at 10:54):

"The Book of Error" sounds great. I already want to read it.

I think it should address error production vs. consumption/libraries vs. binaries/error defining (?) vs. reporting. Personally, this distinction was the "a-ha!" moment after which the Rust error handling ecosystem started to make sense.


Last updated: Jan 26 2022 at 14:20 UTC