First-class error handling with `?` and `catch` #243

glaebhoerl · Sep 16, 2014

After a detour through thinking about first-class checked exceptions, I've now circled back around and convinced myself that @aturon's original idea of an ? operator for propagating exceptions is actually brilliant and the perfect middle path. But I also want try..catch.

CLICKME

This is really great, but I see a potential problem. The RFC does not say anything about how to translate different errors into each other, and I think this is very important. For example, your library may work with several other libraries, each providing its own kind of error, and sometimes you would want to pass these errors to the users of your library. The most natural way is to wrap them into your own error enum, with different variants for different kinds of original errors.

But under this proposal there is no support for such patterns at all. Frankly, I don't know even in the slightest how this can be done in syntactically light and convenient way and even if it is possible in principle. Exceptions in other language do not have this problem mainly due to subtyping and having special Exception supertype, and these features are not present in Rust.

I'm afraid that this can be a very common use-case, and, unfortunatley, ? operator won't help with it at all.

netvl · Sep 16, 2014

This is really great, but I see a potential problem. The RFC does not say anything about how to translate different errors into each other, and I think this is very important. For example, your library may work with several other libraries, each providing its own kind of error, and sometimes you would want to pass these errors to the users of your library. The most natural way is to wrap them into your own error enum, with different variants for different kinds of original errors.

But under this proposal there is no support for such patterns at all. Frankly, I don't know even in the slightest how this can be done in syntactically light and convenient way and even if it is possible in principle. Exceptions in other language do not have this problem mainly due to subtyping and having special Exception supertype, and these features are not present in Rust.

I'm afraid that this can be a very common use-case, and, unfortunatley, ? operator won't help with it at all.

@netvl That's covered by an earlier RFC for error interoperation.

aturon · Sep 16, 2014

@netvl That's covered by an earlier RFC for error interoperation.

Ah, I was just thinking of making an RFC for "functional break" -- exactly your generalized return!

I am leery about most proposed syntactic sugars -- especially one as major as try..catch, and rather instead focus on using adding macros, or extending the macro system as necessary to give us what we want. (Hell, ideally I'd make bool an library-defined (enum) type, and even plain if..else a macro).

What I'd propose that people might actually agree with is simply adding the generalized break/return (Ideally one keyword could do everything, and the other would just be kept around for convenience), and making the try macro take an optional extra argument for a block lifetime:

match 'a: {
    try!('a, foo());
    try!('a, bar());
    Ok(()) // edit: added this so it would type check
} {
    None => ...,
     _ => ()
}

Not quite as pretty as try..catch, but on the other hand requires one only small addition to the language---and one that I'd argue more "rounds out" current features, since we already have loops as opposed to some system of mandatory tail calls, rather then delving it into new territory.

Besides my ascetic aversion to much syntactic sugar, I wonder whether the current demand for more control constructs will change with HKTs, and the design patterns they enable ;), and would vote for waiting until until we know the answer.

Ericson2314 · Sep 17, 2014

Ah, I was just thinking of making an RFC for "functional break" -- exactly your generalized return!

I am leery about most proposed syntactic sugars -- especially one as major as try..catch, and rather instead focus on using adding macros, or extending the macro system as necessary to give us what we want. (Hell, ideally I'd make bool an library-defined (enum) type, and even plain if..else a macro).

What I'd propose that people might actually agree with is simply adding the generalized break/return (Ideally one keyword could do everything, and the other would just be kept around for convenience), and making the try macro take an optional extra argument for a block lifetime:

match 'a: {
    try!('a, foo());
    try!('a, bar());
    Ok(()) // edit: added this so it would type check
} {
    None => ...,
     _ => ()
}

Not quite as pretty as try..catch, but on the other hand requires one only small addition to the language---and one that I'd argue more "rounds out" current features, since we already have loops as opposed to some system of mandatory tail calls, rather then delving it into new territory.

Besides my ascetic aversion to much syntactic sugar, I wonder whether the current demand for more control constructs will change with HKTs, and the design patterns they enable ;), and would vote for waiting until until we know the answer.

P1start · Sep 17, 2014

P1start reviewed Sep 17, 2014

View changes

P1start · Sep 17, 2014

active/0000-trait-based-exception-handling.md

+
+        try {
+            foo()?.bar()?
+        } catch e {


Can’t e just be an arbitrary refutable pattern here, and allow multiple catch arms? So the example below becomes this:

try { foo()?.bar()? } catch Red(rex) { baz(rex) } catch Blue(bex) { quux(bex) }

That way you only need one type of catch block and there’s less rightward drift.

To me that syntax looks like if-let..else, and implies no guarantee of catching all cases. Catch should handle all variants---the alternative gives me bad memories of Java's RuntimeException.

Just make it like match—all cases have to be covered. Just because it looks vaguely like ‘if…let’ doesn’t mean it has to behave like it. I’d immediately assume that all errors have to be handled anyway, regardless of syntax.

I think this is also a reasonable choice. But I think I prefer the match-like syntax because it better matches the actual behavior and meaning, i.e. it makes the reader think of match, rather than of try-catch-catch from other languages, and this is in fact the correct intuition. The alternative would repurpose familiar syntax to mean something similar but significantly different, which I'm a little bit uneasy about.

(But again I think both are basically fine, I'm just explaining my preference.)

IMHO, if something should behave like match, it should look like match.

@glaebhoerl

First of all, thanks for writing another beautiful and thorough RFC. It's always a pleasure to read these.

The ideas you're proposing help overcome one of my worries with the initial ? proposal, namely that it was tied to exiting the function. While this is the common case in Rust code today (probably due, in part, to try!), and you can always factor your code into smaller functions to make it work, the extra flexibility in this RFC seems both appealing and not very complicated.

I also wholeheartedly agree that this design finds a middle ground between completely implicit propagation (traditional exceptions) and completely explicit propagation (Result without try!). It recovers much of the ergonomics of implicit propagation, while keeping control-flow jumps explicit.

I think that throw and throws are promising as well. My main worry there is that throws somewhat muddies the integration with return types, for better or for worse. I suspect it could and should be integrated with closure type syntax, if we decide to include it.

I'm undecided on the Carrier question, in part because we're (still!) trying to finalize conventions around the use of Result and Option.

Have you looked at the error interoperation RFC? Part of the goal there was to allow different error types to be automatically converted when using try!. The reason that works, however, is that the function's return type (and hence the target error type) is always explicitly written. This property would no longer hold with try-catch blocks, so I'm not sure how or whether automatic conversion would apply there. I'd be interested to get your thoughts.

So, on the whole I'm pretty enthusiastic about these ideas, and I think that if we add ?, we should do so in the form proposed here.

However, as you know, at the moment we're setting a pretty high standard for RFC acceptance: we're relentlessly focusing on what is needed for a solid 1.0 release (e.g., backcompat hazards or proposals that are needed for overall usability or coherence for 1.0). After the release, we will of course start considering more "nice-to-have" features.

Personally, I feel that having a solid error-handling story is an important aspect of 1.0, which is part of why I've been pushing on various related aspects (both conventions and sugar). It's not clear to me whether try! is enough to make a good first impression, but we also have our hands rather full implementing already-accepted features. It might be possible to accept this RFC but explicitly not as a 1.0 blocker; I'm not sure, but I'll discuss it with the team.

Two final questions:

If we have a ? operator as proposed here for error handling, does that change your opinion about !? What if, independently, macro syntax was changed to use @ (which has been separately proposed; I know you're not fond of that, but hypothetically?)
Do you have thoughts on the minimal steps we can take pre-1.0 to ensure that we can implement this feature later? The main issue seems to be the try keyword, which of course conflicts with the try! macro. It's probably feasible (if confusing/ugly) to allow both, i.e. to treat ! as part of the identifier. Alternatively, we could rename try! -- any suggestions?

Actually, one possibility would be to implement ? as it was originally proposed (i.e., limited to returning from the current function) and then dump or rename try!. Rust code written in that style would continue to feel idiomatic if/when the rest of this RFC was implemented.

(As an aside, Standard ML at least has a form of try/catch that yields an expression.)

aturon · Oct 3, 2014