fn foo () -> Result<(), E1> { .. } fn bar () -> Result<(), E2> { foo()?; } This requires `bar` to have a function signature that notes it may e

fn foo () -> Result<(), E1> { .. } fn bar () -> Result<(), E2> { foo()?; } This requires `bar` to have a function signature that notes it may error, `E2` must implement `From<E1>`, and the caller of `bar` must use the result or explicitly silence the warning. Meaning if a program creates a Result the error must be handled - you can't silently let errors bubble up through the call stack. `Result` implements some common combinators like `.ok()` to convert to `Option`, `map`, `map_err`, `or_else`, etc to reflect the common cases of error handling. And finally, since Result doesn't require non-local control flow like exceptions you know that `drop` will run as the functions return back up the callstack. And if you want to use Result like exceptions... you can. But you can't hide it from callers, and callers are still free to handle them elegantly.