That might be true, but while a big part of it got implemented, the current state AFAIK also deviated from that RFC a bit and the naming wasn't widely adopted. For example, the Rust Book mentions „throw“ three times, two of which are „Throws a compile time error“. On the other hand, „error“ and „failure“ seem to be much more common there, so I think it makes sense to stick with something like that.
Exception type upcasting
Wouldn't that happen to be the first and only true „type upcasting“ in Rust? (I don't know if type → dyn Trait is considered upcasting, might be). But again, bringing terminology and somewhat emulating object oriented languages that have inheritance feels non-Rusty.
I believe this topic is not related to error handling but a goal what EnumX aims to achieve. Some existing crates are ready on crates.io. And I have posted a Pre-RFC, however, “impl enum” not involved yet.
That's actually what I'm trying to say. While impl Enum (or whatever else, subject for bikeshedding) would help in more places than just error handling, it would also improve the comfort of creating new error types. Such solutions seem to be strictly better, because they generalize.
As far as I know, Rust’s iterators are lazy, so it is not required to do early exit from several levels of call stack until consuming. As I mentioned in previous post,
try_fold()is up to this job( correct me if I am wrong ).
Iterators are just an example. To return from my own function from a closure I pass into some other higher-lever function would make my code simpler in many occasions. I see try_fold as kind of a patch for the problem, its existence actually showing that there's the problem. It is up to the job in the same sense as return Err(e) is up to the job of error handling ‒ it gets it done, but one desires for something less cumbersome.
Both @kornel and you mentioned this. But I am still not very clear about the
?issue.
Again, ? is just one example, but what I was trying to say is, even the ? that was motivated for error handling is generalized. But Result is just an enum, Box is just a type (AFAIK there was a time when it was a sigil or keyword), etc. The throws thing that seems to create the error type behind the scenes look a lot like it is very much just to build a Result and nothing else. It puts error handling into a special position and pushes other „control“ types and such into background, which feels like some kind of violation of how Rust feels now ‒ instead of special casing some (yet very common) thing by giving it keywords and baking it into the language, a lot of things are handled by giving the library good enough tools to build them comfortably and more besides.
I agree there are ways to improve error handling in Rust, I just don't see that giving a new syntax to things we already have is an improvement. In other words, the sum enums idea looks like good direction to me ‒ it allows to build error handling and more. I'd also like to see how far things like failure 1.0 gets us before proposals for extending the language (as opposed to eg. adding types to the std) start ‒ I see changes to the syntax as the last resort thing, if everything else fails.
Is there any other problem than just being able to create the sum error type comfortably CeX tries to solve? I might have invested too little time into studying what it does, but it feels like just giving you that.
(I know the CeX itself just uses macros, but if I understand it correctly, this is more like to experiment with things ‒ the syntax as a whole feels unsatisfactory somewhat)