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

[kornel]

The idea for function syntax sugar has been discussed before, e.g. try fn

Pre-RFC: flexible `try fn`

This approach is a bit extreme, but, I think, worth exploring. Relevant topics: RFC2426: throw expressions Pre-RFC: Catching Functions UPD: If you don’t want to read the whole discussion I recommend to check this @Centril’s comment. Summary Introduce try fn and throw/fail/etc. keyword (throw will be used here for now), which will allow us to write the following code: try fn foo() -> Result<u64, MyError> { // returns Ok(10), i.e. happy path is Ok autowrapped if early_return() { retu…

and

Pre-RFC: Catching Functions

This is an alternative design to Ok wrapping, which I am very excited about. Similar ideas have been floated in the past. Each subheading can be separated: The throw keyword The throw keyword has the semantics: throw $expr <=> return Err(From::from($expr)) This makes ? sugar for: match expr { Ok(x) => x, Err(e) => throw e, } The throw keyword is added mainly for assisting in raising errors, replacing Err(e)? expressions. This integrates well with designs in which your errors may ne…

---

Note that previous proposals considered OK-Wrapping as an important feature.

The ?? syntax can't be used, because it's taken already: Ok(Ok(2))??; is valid today.

This seems to be very Result-specific. Currently ? is generic and supports other type like Option. Any "throw" syntax should probably be a lower-level concept that could also be mapped to custom enums, compose with async functions, etc.

Some form of ad-hoc enum may be useful, but it should also be a separate RFC. Rust tries to have orthogonal simple features that are building blocks for other features, not special-case ones (e.g. Rust has enum that allows making Option as a library feature, as opposed to nullable types in Swift which are built-in magic).

And logging is a completely separate thing. While logging is a commonly used functionality, I'm not sure if we've reached the point where we're certain enough of its implementation to cement it in the standard library. It's probably best to leave it out. It seems like a thing that can be easily added with traits without being built-in into the language.