feature: improve error_handling exercises

[tlyu]

Move result1 to errors4 and put it in the error handling section. Fixes #719.

Add new exercises errors5 and errors6, to introduce boxed errors and
custom error enums more gently. Delete errorsn, because it tried to do
too much too soon. Fixes #756.

[tlyu]

Thanks for the review! I agree with most of your changes.

I was planning to have map_err in one of the advanced exercises, but now that we've talked about passing functions instead of closures to map_err (because closures aren't used yet at this point in the exercise sequence), I guess it could go in this exercise.

Is there a consensus for error enum variants with payloads? I think I've seen both 1-tuple structs and structs with named fields. Are there tradeoffs involved? (I suspect there are, involving public vs private visibility of fields, but I'm not sure.)

std::num::ParseIntError does have a payload, though it's a private one at the moment, so I guess we shouldn't wrap that?

[yaahc]

Is there a consensus for error enum variants with payloads? I think I've seen both 1-tuple structs and structs with named fields. Are there tradeoffs involved? (I suspect there are, involving public vs private visibility of fields, but I'm not sure.)

I don't think there is a clear consensus. There should be no difference in field visibility since all fields in enums are pub. The main difference is how the constructor is exposed. For a struct variant it uses the constructor syntax, but for unit variants the compiler essentially adds a function with the same name for the constructor. And I think I can see where you're going with this question.

enum WrappingError {
    Inner(InnerError),
}

struct InnerError;

fn main() {
    // The turbofish is only needed here because rustc can't infer the `T` parameter here.
    // This just set's it to () so the compiler leaves me alone, most code wouldn't need this turbofish
    Err::<(), _>(InnerError).map_err(WrappingError::Inner);
}

This is possible with tuple variants but not with struct variants, so it will probably be easiest to teach the tuple version since it provides the needed conversion function out of the box.

[yaahc]

std::num::ParseIntError does have a payload, though it's a private one at the moment, so I guess we shouldn't wrap that?

I don't understand what you mean. The ParseInt payload is internal so we don't have to worry about it, but if anything the fact that they're not all identical and they have different runtime instantiations of that type means that we really need to wrap it, if we try to replace it with our own equivalent error type we will probably provide less information than the original error did.

[tlyu]

I don't understand what you mean. The ParseInt payload is internal so we don't have to worry about it, but if anything the fact that they're not all identical and they have different runtime instantiations of that type means that we really need to wrap it, if we try to replace it with our own equivalent error type we will probably provide less information than the original error did.

Yeah, I guess you're right. Even if we can't make decisions based on those private variants, they're still relevant for display purposes.

[tlyu]

This is possible with tuple variants but not with struct variants, so it will probably be easiest to teach the tuple version since it provides the needed conversion function out of the box.

I hadn't realized that tuple struct constructors actually were proper functions! I thought they were special struct expression syntax that happened to look like function calls. I'm not sure this exercise is the right place to introduce that concept. Or maybe it is? It seems likely to cause confusion if it hasn't been mentioned before.

[yaahc]

I hadn't realized that tuple struct constructors actually were proper functions! I thought they were special struct expression syntax that happened to look like function calls.

hehe, yea. This comes up when you're re-exporting items in a library. If you a type alias to bring it in it will only import the type, but not the function, where as if you export it with a pub use it will bring in all items with the same name from all 3 namespaces.

I'm not sure this exercise is the right place to introduce that concept. Or maybe it is? It seems likely to cause confusion if it hasn't been mentioned before.

I think you're right on this, methods are less confusing and will more naturally lead into teaching about From impls.

[yaahc]

lgtm

[shadows-withal]

i trust your judgement @yaahc