Stream: project-error-handling

Topic: rustlings


view this post on Zulip Taylor Yu [they/she] (Jun 09 2021 at 01:48):

so i quickly worked through the rustlings course and got frustrated with the conversion exercises, where i wished i could have used ? in lots of places, but often the error type was simply String. i submitted a patch to change that to Box<dyn Error> for easier use of ?. that turned out to cause other users to be confused, so i started reading in more detail about error handling in Rust

view this post on Zulip Taylor Yu [they/she] (Jun 09 2021 at 01:49):

thinking about it more, i realized there was a large jump in difficulty in the error_handling exercises: https://github.com/rust-lang/rustlings/issues/756 so i submitted the previously mentioned pull request https://github.com/rust-lang/rustlings/pull/772 with some improvements

view this post on Zulip Taylor Yu [they/she] (Jun 09 2021 at 01:52):

there's a bit of a sequencing problem because some more advanced Rust language concepts are needed before teaching some of the other best practices: mapping errors with map_err etc require familiarity with closures, for example, so having custom error types that wrap other errors has to wait for that. similarly, implementing From, which is needed for the ? operator to work cleanly with custom error types, needs to wait until after the conversion traits are introduced

view this post on Zulip Sean Chen (he/him) (Jun 09 2021 at 14:17):

Yea, Jane's been brainstorming an API for a concrete wrapper type around Box<dyn Error>s (which you can see here), not specifically to address this, though I wonder if it would have the added benefit of being more appropriate to introduce at an earlier point in rustlings, since it would just be a struct called DynError that wraps a Box<dyn Error>. I'm thinking this way newcomers only have to wrap their brain around a single error type and how to work with it instead of being exposed to Box, dyn, and the Error trait all at once.

view this post on Zulip Taylor Yu [they/she] (Jun 09 2021 at 15:26):

that does have some appeal, though i wonder if it would take a while to reach consensus on it. i guess a big part of the general problem is that Result<T, E> is quite versatile and underconstrained, and existing tutorial materials don't provide much guidance about what to use as E. (and include some worst practices such as Result<T, String>)

view this post on Zulip Jane Lusby (Jun 09 2021 at 15:26):

it's definitely far too early for it to go into rustlings though

view this post on Zulip Jane Lusby (Jun 09 2021 at 15:26):

we still need to actually test it out for a while, particularly given that there are already concerns about how teachable it will be

view this post on Zulip Sean Chen (he/him) (Jun 09 2021 at 15:26):

it's definitely far too early for it to go into rustlings though

Sure; just a thought :smile:

view this post on Zulip Jane Lusby (Jun 09 2021 at 15:27):

since this approach would introduce a separate Result type

view this post on Zulip Jane Lusby (Jun 09 2021 at 15:27):

it's a good idea, but yea, just not yet

view this post on Zulip Sean Chen (he/him) (Jun 09 2021 at 15:30):

Does rustlings cover defining error enums to capture different error variants? I feel like that could be introduced earlier than Box<dyn Error>, though you'd still have to introduce the Error trait and deriving it for the error enum.

view this post on Zulip Taylor Yu [they/she] (Jun 09 2021 at 15:33):

that's partly what my current PR is trying to do. one thing i realized that would make the teaching easier is that you don't have to implement all of error::Error to get some of the benefits of using custom error types. like you can use ? as soon as you have all the required From<E> for MyError traits implemented

view this post on Zulip Taylor Yu [they/she] (Jun 09 2021 at 15:39):

right now the error_handling section of rustlings comes before anything that uses closures or conversion traits. so it might make sense to add an advanced_errors section that comes after those, so we can teach map_err (to help with custom error variants that embed a lower-level error) and From<E> for MyError (so ? can work nicely). and then later on teach Display and the full error::Error trait, probably via an exercise that simulates an application calling a function returning the custom error but returns a boxed error (so the custom error would have to fully implement Error)

view this post on Zulip Jane Lusby (Jun 09 2021 at 15:40):

we should probably also teach .ok_or if that isn't already in rustlings somewhere

view this post on Zulip Jane Lusby (Jun 09 2021 at 15:41):

reviewing your PR right now btw

view this post on Zulip Taylor Yu [they/she] (Jun 09 2021 at 15:43):

yeah, i had been wondering why so many helpful methods on Option and Result aren't really covered at all in our tutorial material. i'm actually writing up method overview sections for Option and Result for the std docs, including "truth tables" for the boolean-like operators/combinators

view this post on Zulip Jane Lusby (Jun 09 2021 at 15:44):

fancy

view this post on Zulip Taylor Yu [they/she] (Jun 09 2021 at 15:46):

oh, another thing i just realized: mapping functions can take ordinary function pointers as well as closures, so that's one way to sidestep introducing closures (though i think currently rustlings doesn't explicitly teach closures; it might drop them directly into an iterators exercise without introduction?)

view this post on Zulip Sean Chen (he/him) (Jun 09 2021 at 15:49):

I feel like function pointers are encountered way less often in Rust than closures (though maybe that's just me?), which is to say I'm not sure if a newcomer would know what a function pointer is in the context of Rust (though they might certainly have seen them in other language contexts).

view this post on Zulip Sean Chen (he/him) (Jun 09 2021 at 15:49):

Rustlings not covering closures seems like a gaping hole though..

view this post on Zulip Jane Lusby (Jun 09 2021 at 15:50):

im assuming they just cover it later

view this post on Zulip Jane Lusby (Jun 09 2021 at 15:51):

and yea, using a fn sounds like a good idea

view this post on Zulip Jane Lusby (Jun 09 2021 at 15:51):

you could do something like fallible_fn.ok_or(MyError::from)

view this post on Zulip Jane Lusby (Jun 09 2021 at 15:57):

that way you don't have to introduce even more boilerplate than would normally be needed

view this post on Zulip Taylor Yu [they/she] (Jun 09 2021 at 15:58):

yeah, and it could even be an ordinary associated function, to avoid introducing the From trait too early

view this post on Zulip Jane Lusby (Jun 09 2021 at 15:59):

Taylor Yu [they/she] said:

yeah, and it could even be an ordinary associated function, to avoid introducing the From trait too early

aah, i didn't realize it hadn't been introduced yet by the 6th error exercise

view this post on Zulip Jane Lusby (Jun 09 2021 at 15:59):

was trying to avoid having functions / methods just for each from impl that would be needed, but i guess that's fine since you will clarify later

view this post on Zulip Taylor Yu [they/she] (Jun 09 2021 at 15:59):

currently, generics come after the error handling section

view this post on Zulip Jane Lusby (Jun 09 2021 at 15:59):

and actually that leads well into From

view this post on Zulip Jane Lusby (Jun 09 2021 at 16:00):

since you can be like

view this post on Zulip Jane Lusby (Jun 09 2021 at 16:00):

"remember this? actually doing this every time is annoying, so we have a trait for it!"

view this post on Zulip Jane Lusby (Jun 09 2021 at 16:00):

or smth

view this post on Zulip Jane Lusby (Jun 09 2021 at 16:00):

Taylor Yu [they/she] said:

currently, generics come after the error handling section

I liked your earlier suggestion about having an advanced error handling section

view this post on Zulip Jane Lusby (Jun 09 2021 at 16:00):

might be that we just teach most of error handling in the advanced section

view this post on Zulip Jane Lusby (Jun 09 2021 at 16:01):

have whatever simple examples we can for pre generics and closures

view this post on Zulip Jane Lusby (Jun 09 2021 at 16:01):

then do a full tutorial later using all the necessary features

view this post on Zulip Jakub Duchniewicz (Jun 13 2021 at 10:35):

coming late to the party, it would be a good idea to separate EH into two parts, basic one and advanced, just like the Rust Book does

view this post on Zulip Jakub Duchniewicz (Jun 13 2021 at 10:39):

also it's good to know that so many people learn from rustlings (for instance I did not know they were so popular)

view this post on Zulip Jakub Duchniewicz (Jun 13 2021 at 10:40):

and amazing job on the truth tables (I ALWAYS have to look up the documentation to see what the functions do)

view this post on Zulip Jakub Duchniewicz (Jun 13 2021 at 10:41):

which brings up the topic of not verbose documentation in several places

view this post on Zulip Jakub Duchniewicz (Jun 13 2021 at 10:41):

or not concise enough

view this post on Zulip Taylor Yu [they/she] (Jun 25 2021 at 02:37):

another pull request to hopefully alleviate some confusion caused by boxed errors https://github.com/rust-lang/rustlings/pull/780

view this post on Zulip Taylor Yu [they/she] (Jun 25 2021 at 22:01):

advanced errors: https://github.com/rust-lang/rustlings/pull/781

view this post on Zulip Jane Lusby (Jun 25 2021 at 23:08):

just wanna give you a heads up @Taylor Yu [they/she] that I probably wont be able to review these until monday


Last updated: Jan 26 2022 at 14:20 UTC