Pre-RFC: Catching Functions

language design
248

Wanting to make Rust error handling look more like throwing and catching exceptions.

I think this one can be drilled into deeper:

  • Wanting an explicit syntax for raising errors
  • Wanting fallible code to look as-similar-as-possible-but-no-closer to infallible code
  • Not wanting the existence of fallible code in a method to affect how infallible code in the method is written
  • Wanting a method that never fails, but is "fallible" for external reasons (like trait signatures) to have a body that looks the same as if it were infallible.

(Sorry for mostly writing the same thing three times there, but I couldn't decide which perspective I liked best.)

It could also mean things I don't think I've seen expressed, though please correct me if I missed them

  • Wanting finally blocks
  • Wanting an integrated construct that handles both try and catch, in the C++/Java sense
  • Wanting all methods to be allowed to throw, without it being visible in their signatures
  • Wanting all errors to propagate upwards without me needing to do anything

A bunch of my things from 2107:

  • Not wanting to type Ok(()) any more than one wants to type ()
  • Wanting to rearrange lines in a fallible method with minimal edits
  • Wanting to have ? after every fallible method call (that doesn't need custom handling)
  • Never wanting to write something like Ok(foo()?)
  • Wanting all returns in a method to take the same type
  • Not wanting a T -> Option<Option<...<Option<T>>...>> coercion
  • Not wanting this to be Result-specific
  • Particularly wanting this to work great with [T]::get, Iterator::min, i32::checked_mul, etc
  • Wanting to see the return type of the function written out
  • Wanting main in examples to still look good when it returns Result to allow ?
  • Wanting existing doctests to continue to work even if the signature of the implicit wrapper is changed to allow using ? in them
  • Not wanting a syntax that repeats information from the Try impl for a type
  • Wanting something that works with closures as well as fns

I think, for now, I'll go back to using my old amusing-but-clearly-unacceptable syntax for this feature to avoid bikeshedding:

fn add_opt(a: Option<i32>, b: Option<i32>) -> Option<i32> ¿{ a? + b? }
8 Likes