[Closed, with a new one] Checked exception simulation in Rust( 2nd version )

[oooutlk]

Thanks for your reply which is extensive and helpful for me to go further. @vorner

---

Naming issue

@vorner

I find all the ideas about adding exception-like terminology both misleading (if it isn’t exceptions, use different syntax so people know they are not exceptions) and alien to Rust.

I have no strong opinion about the syntax or naming. That's why CeX supports both throws syntax and style of writing vanilla Rust as fallback. In perspective of EnumX, "throw" is into_enum() and "rethrow" is exchange_into(). But the latter names tend to be not related to error-handling. If someone got more proper names than throw, I will be glad to adopt them.

However, the terminology "exception" is not introduced in recent discussion. In RFC 0243-trait-based-exception-handling.md, "exception" appears 79 times, "throw" 22 times. This RFC regards "Rust exception" as "a lightweight(in syntax) but explict propagation of early return with Err":

Requiring an explicit ? operator to propagate exceptions strikes a very pleasing balance between completely automatic exception propagation, which most languages have, and completely manual propagation, which we'd have apart from the try! macro.

And I considered CeX to be an immediate successor to RFC 0243:

Exception type upcasting

In a language with checked exceptions and subtyping, it is clear that if a function is declared as throwing a particular type, its body should also be able to throw any of its subtypes. Similarly, in a language with structural sum types (a.k.a. anonymous enum s, polymorphic variants), one should be able to throw a type with fewer cases in a function declaring that it may throw a superset of those cases.

---

EnumX related issue

@vorner

maybe some kind of anonymous sum types (so I could write something like Result<T, impl Error (std::io::Error | MyCustomError)>

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.

---

Early exit issue

@vorner

inability to traverse several levels of call stack at once, eg returning from within vec.iter().map({…}). I don’t have a solution for that, but this is clearly not addressed by just adding a throws keyword.

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 ).

---

Generalization issue

@vorner

c) are general beyond just error handling (eg. ? also works on Option and will work on futures and you can add your own too)

Both @kornel and you mentioned this. But I am still not very clear about the ? issue. CeX does not develop its own ? mechanism: ~?/~~? are not new operators but are a combination of ~/~~ and ?. However I am planing to add a dev branch in the github repo to do experiments and verifications of the idea. Would you plz show me some sample code which ought to be supported but not yet by CeX?