Bikeshed: Rename `catch` blocks to `fallible` blocks

[elahn]

+1 for try

@gbutler, ? will be able return anything that implements the trait Try, not just Result<T,E>.

[gbutler]

OK, but, it will still be returning some kind of value, not throwing/raising an exception, which is the traditional association of “try”. That’s why I proposed, “returned” because it aligns with what is going on. A value (either a Result<T,E> or something else that can be the desired value type or something returned as an error by ?) is being returned from the block as the value of the block. No exception is thrown or raised which is what most people will think if they’ve come from other languages.

[SheepKey]

I like trap the most, because it is completely unrelated to exception terminology from other languages and hence not confusing. It clearly communicates what is happening and sounds like an error-handling-related thing.

It is also short and concise, unlike returned, etc. I like concise and clear syntax without excessive typing.

Otherwise, yes, try is definitely better than catch.

[gbutler]

Someone coming from another language (JS, C#, C++, Java, D, etc, etc) will all be wondering, “I see ‘try’, but, where is the ‘catch/finally/???’” and how come I can’t “raise/throw” inside the “try” block.

EDIT: Again, I’ll “Raise” the objection that using any of “try/catch/finally/throw/throws/raise/raises” in relation to this is going to cause endless confusion and will result in constant acrimonious criticism of Rust due to its co-opting of keywords to have a meaning not in line with the mainstream. It will also become a discussion point along the lines of, “Why is Rusts EXCEPTION HANDLING so F----ed up? Why are Exceptions not thrown? Why is it sometimes a return value and other times you can “try” with an implied “catch”? Don’t these Rustaceans have a clue as how EXCEPTION HANDLING works? Why doesn’t it automatically unwind the stack? Why???..etc”. I can hear the wailing and gnashing of teeth already.

[rpjohnst]

I don’t think it’s anywhere near that bad. The fact that there isn’t a corresponding exception handler or finally block attached to this thing is a pretty obvious tell that something is slightly different, and that it’s time to look up what that is.

We’ve also already got the Try trait, which you might easily think of as the operator-overloading trait for try+?, analogous to Add for + or Index for []. In fact, the ? operator used to be a standard library macro called try!, so the name isn’t even new.

And for that matter, Rust already has a reputation for doing error handling “differently.” Nobody is going to complain about this any more than they already do just because we introduce try blocks instead of resultof blocks.

[Xanewok]

I’m mostly lurking here and wasn’t really active in previous catch-related changes/RFCs. Truth be told I’m not really satisfied with what’s currently proposed and since this will inevitably land at some point and I really like @scottmcm 's suggestion, I’d like to defend this bikeshed will all the spare bike tires I have

First of all, I think it perfectly describes what fallible { ... } blocks are and what should do. I personally parse it as a ‘fallible’ expression, which naturally means ‘expect a value representing a possible failure’. This aligns with the semantics, where the expression inside will always return either a Result or an Option (or other Try implementers?).

When talking about evaluating an expression returning a concrete fallible value this also somewhat naturally implies short-circuiting (how would you evaluate the expression further if you have an error early and what else would you return?), which is what it’s for in the first place.

There’s also another teaching/ecosystem/community benefit - people are already used to the term and despite not being as simple as try, associate it with something that returns a Result or what can fail in general. A good example might be the fallible collections RFC, fallible-iterator crate or the fallible term/Infallible used in TryFrom.

Regarding reusing the widespread exception handling syntax and:

This is how I see it too. Let me expand a bit. I think that there is a belief – one that I have shared from time to time – that it is not helpful to use familiar keywords unless the semantics are a perfect match, the concern being that they will setup an intuition that will lead people astray. I think that is a danger, but it works both ways: those intuitions also help people to understand, particularly in the early days.

I think exceptions are a pretty hot topic when talking about programming languages and very polarising. In this particular case I think reusing the catch syntax might do more damage than good, as I believe one could expect that the underlying code can throw exceptions and introduce non-trivial control flow where in fact we just limit the scope for short-circuiting evaluation.

However, if we were to use the exception-related syntax, I’d also lean more towards try (we ‘try’ to do something, rather than use it to handle errors; basically what @Ixrec said and we have a Try trait for short-circuiting).

[gbutler]

EDIT: re-reading what I wrote here, I think it may have come off more accusatory/harsh than I intended. I only intend to point out my strong feeling that “try”/“catch” or related words just don’t feel right (to me) and I’m wondering how much of the support for “try” (or “catch”) comes from just feeling it should be what is used because it is generally what is used as opposed to having a strong feeling one way or the other.

I’m still not sold on the idea of using “try”. It seems to me that:

let x = whatever_keyword_is_chosen {
   let y = something_else(something?)?;
   process(y + 2)? * 3
};

Is really a short-hand for:

let x = ApplyLambda( || {
   let y = something_else(something?)?;
   process(y + 2)? * 3
});

Which, again, argues for using something like “returned” or “resultof” to emphasize the notion that Rust handles error conditions by returning Error/Fallible values or the desired Value from functions, not by raising errors, stack unwinding, etc.

NOTE: In the above I’m using some pseudo-code just to convey the notion of what I’m getting at.

I honestly feel like everyone arguing for “try”, “catch”, etc. wish (perhaps without even being completely aware of why) that Rust just had exceptions like other languages and really don’t like the fact that Rust uses Result<T,E> etc. It seems like everyone just wants to make it look like exceptions in other languages even though it isn’t. Maybe it is even subconscious (i.e. “it feels like it should be that way because that is what [we’re] used to”).

Personally, I really like the direction of Rust error handling and think it makes sense to emphasize the fact that it is returning value/error not raising exceptions/stack unwinding.

In fact, because “Panic!” is effectively an “Exception” that can’t be caught (akin to a RunTime exception in Java that shouldn’t be caught with the additional restriction that it CAN’T be caught, except at a thread boundary) that making it absolutely 100% clear that Rust error handling ARE NOT exceptions is the most advisable thing to do.

Again, this is just my opinion, but, and opinion I strongly hold. I would ask everyone to really consider why they want something like “try”? What makes you lean in that direction? Is it justified by the nature of what Rust is doing/embracing or is the only justification some notion of using terminology familiar to other exception-based languages? If the latter, why is that a good thing? Really think about it.

[elahn]

I love Rust error handling. I hate exceptions as the normal mode of error handling; panic is fine. I fully understand your objections and I’m familiar with error handling in several other languages, but try does not make me assume exceptions. I still prefer try and others have already expressed my reasons for why. I would also accept fallible without complaint.

To me, try means: intercept any control flow actions due to errors in this block and continue on the next statement/expression. It means the same thing in Rust as other languages I’m familiar with.

[Xanewok]

Just to be clear, I really like Rust’s error handling story, that it uses Result values and similar, so I think we both agree here. I also would really like if we move on from catch/exception terminology here.

I already explained why I feel fallible sort of naturally conveys the semantics that will be used.

However, if we were to use try/catch, I’d prefer try much more, simply because it’s more innocuous and natural ('try that, at worst we’ll get Err') rather than catch ('catch what? that’s like catching exceptions, but where’s the regular catch block where I handle incoming error?).

To sum it up, go team fallible , but we can also try try! (OTOH fallible is considerably longer…)

[gbutler]

I agree that “fallible” as the keyword works much better than “try” or “catch”.

[jsgf]

I was going to object to try on the basis that it seems like too prime a variable name to be claimed by a keyword, but I think in practice I’ve never used it and the try!() macro has already claimed it (in a figurative rather than literal sense) for quite similar purpose. But maybe that’s just Rust old-timer thinking.

(If I could have my wishes magically enacted retroactively, Rust would use typedef rather than type - it’s my number one keyword/desired symbol collision.)

[kornel]

I like try.

• It’s a syntax sugar, so the shorter keyword the better (do might work too, but it’s not obviously error-handling-related).
• In languages with try/catch the “run this code until an error” part is contained in the try block, not the catch block.
• Swift has similar try? for wrapping exceptions in optionals. It also has do { try } catch error { }, so compared to it Rust’s try would be more similar, and catch more confusing.

[steven099]

• In languages with try/catch the “run this code until an error” part is contained in the try block, not the catch block.
• Swift has similar try? for wrapping exceptions in optionals. It also has do { try } catch error { }, so compared to it Rust’s try would be more similar, and catch more confusing.

Both these points seem misleading.

• The fact that the try block means “continue until error” is misleading because it doesn’t mean “and contain the thrown error”. In languages with try-catch, try only serves to put a bound on where fallible code may occur—on its own it doesn’t contain the thrown errors. The former is the role served on a more granular level by ? in Rust (and try in Swift).
• In Swift, try means the same thing as ? in Rust: a fallible operation that evaluates to the success branch, with the error branch being handled non-locally. Focusing on try? coalescing the success and error branches into a single value ignores the fact that this meaning is provided by the ? and not the try.

In languages with try-catch, catch applies to the preceding block. The block following catch consists of handlers describing which errors it can handle and how. In Rust’s expression-oriented model, it makes sense for catch to be a prefix operation rather than a postfix one, especially since Rust doesn’t need a place to put inline handlers: it doesn’t need to evaluate to (), it only needs to evaluate to Result<T, E>.

[repax]

I think the meaning of try in context is quite easy to grasp:

let result = try {
    // Here's an attempt at doing something.
    // Needless to say, it may succeed or fail.
}

The meaning should be obvious to anyone coming from a try...catch background. Catch isn’t needded because the value/error is captured as the value of the try block.

[jlgerber]

As someone just picking Rust up (6 months?), who flits from language to language, I actually appreciate the familiar terms such as try, do and catch, even though the proposed semantics are different in Rust than in other langauages. The fact that the terms point in the general vicinity of error handling provides a toe hold which is useful when starting out.

I personally find both fallible, resultof very noisy. I am much happier typing enum than taggedunion, even though enum behaves differently in Rust than in say c or c++.

I prefer monosyllabic keywords (so I am happy with trap) as they seem to be easier to soak in; they are more “restful” on the eyes when scanning code (at least for me. subjective i know). We are going to be typing and reading these a lot, so making them short and tidy is paramount IMHO.

Thought I would provide a “newbie” perspective. Thanks for all the great work on Rust.

[steven099]

I think the meaning of try in context is quite easy to grasp

One point which supports this argument is the presence of try_something functions in the standard library. These functions all return Result. By this pattern, a try operation is a fallible operation that returns a Result value representing the success and failure cases. This understanding works for both try_ functions and
try { ... } expressions.

One question I have is how this would translate into a function-level syntax (which has been proposed from time to time). With catch you can have -> Result<T, E> catches or -> T catches E or variations with just catch in them instead. try doesn’t really suggest anything, except maybe try fn ..., which would stutter in the case of try fn try_something() .... I know some people are partial to throws, but that doesn’t accurately describe something a function can do (only the ? operator can actually “throw”).

[repax]

One question I have is how this would translate into a function-level syntax

There are many opinions here. How about:

fn foo() -> Result<T, E> try {
    ...
}

That makes it similar to:

let result = try {
    ...
}

The idea is that try belongs more to the block than the fn header, if that makes sense.

With fn foo() -> T catches E the function implementation affects how the function signature is declared. Therefore I would prefer if the return type declaration remains Result<T, E>, even though there are some good arguments for T catches E

At least I don’t see any problems with try { for function blocks.

[rpjohnst]

That could be done with single-expression functions, which would equally apply to other block-like structures:

fn foo() -> Result<T, E> = try { ... }

[steven099]

That could be done with single-expression functions, which would equally apply to other block-like structures:

fn foo() -> Result<T, E> = try { ... }

That handles tail expressions, but not return statements. With T as (), you’d still have to write return Ok(()) instead of just return, for example.

There are many opinions here. How about:

fn foo() -> Result<T, E> try { ... }

That makes it similar to:

let result = try { ... }

The problem with this similarity is that suggesting the function body is a try block doesn’t capture the behaviour of return (as mentioned above). One place the confusion between the two becomes acute is in closures:

let closure = |x| try { ... };

Here, the function body actually is a try block and should behave as such, but people might be forgiven for expecting it to behave the same with respect to return as a function written as:

fn foo() -> Result<T, E> try { ... }

It creates a subtly wrong intuition. I do agree that we’re describing more the function body than the function itself, though. I liked the -> Result<T, E> catches { ... } variant. I’m not sure that -> Result<T, E> tries { ... } makes sense, by comparison.

Edit: This is a little off topic, but I think it’s worthwhile considering the effects on related features.

[scottmcm]

Here, the function body actually is a try block and should behave as such

Well, it’s a shift-reduce conflict in the grammar that would need to be resolved. I think in this case we could easily pick it being interpreted as a “try function”, since there’s never a reason to have a top-level try block in a function – it just scopes where ? applies, and the default is already to the whole function, which is equivalent to what happens with a top-level try.