An alternative proposal to `try`/`catch`/`throw` error handling

[Centril]

The provided semantics can be a lot richer than is possible with builtin language syntax in the current context of error propagation.

We already discussed this a bit on IRC; But… Let me talk a bit about this from a purely technical perspective of expressive power why this statement is factually incorrect or at least misleading to say “a lot richer”.

Let’s start by calling label-break-value + try {..} mechanisms with the special label 'try as Proposal A and the main proposal in this thread Proposal B.

We can technically include 'try in A because try becomes a reserved keyword. This magical label 'try refers to the innermost try {..} or the enclosing closure / function if there’s no try {..}.

There’s only one difference in expressive power assuming try {..} blocks Ok-wrap. Even so, ok!(expr) can easily substitute for Ok(expr) at the tail expanding to break 'try Ok(expr).

If they do not Ok-wrap, then the sum total of proposal A is more powerful than proposal B because of the type based reasoning only the compiler could do (but doesn’t have to, if we don’t want it to…) whereas macros only work on token trees.

The 'try label let’s you target it with break 'try expr which can be wrapped in macros to implement the macro based mechanisms you discuss. Most of these mechanisms are also some form of succeed!(expr) or fail!(expr) + extra behavior on top so given fail expr, you could use it as a primitive for macros.

Ostensibly, one difference where try { .. } is more constrained is that it requires the resulting expression to implement Try;

---

Now that I’ve gotten the more technical aspects out of the way; let me discuss some more subjective points.

Getting back to the Try trait from my subjective POV, I think most cases where you want to bubble up have the Try trait semantics in some form (maybe more general with @scottmcm’s work…)

Users wishing to use these semantics can easily opt-in to them.

My preference is that this should be opt-out rather than opt-in. I do think that try { .. } should be idiomatic.

Unfamiliar users are still given hints that additional semantics might be in play.

I find unfamiliarity with try { .. } and throw expr to be unlikely despite differences in operational semantics and typing rules.

we build up from existing Rust control flow.

I don’t think that is an accurate description; 'escape constitutes a magical label that adds to the language. I also think that the form 'escape: { .. } is much too subtle for such important control flow and inconsistent with the language at large for the moment; I understand that it is meant to be hidden under a macro; but at this point, you are just eventually reinventing try { .. }.

I also think that the rules for try { .. } are pretty well discussed by now; the remaining point of contention seems to be Ok-wrapping.

[phaylon]

@Centril So, the difference of opinion seems to be that you’d like to implement try blocks and built on top of those.

I’d respond that the core point of the issue is to allow delying of the try/catch/throw strategy, including try and allow experimentation and consideration of the error handling strategy as a whole.

Ostensibly, one difference where try { … } is more constrained is that it requires the resulting expression to implement Try;

I believe that is quite a big constraint. Experimentation would be more open if the control flow option were available in many scenarios, like custom composable DLSs not needing to resort to closures and return to implement early propagation.

My preference is that this should be opt-out rather than opt-in. I do think that try { … } should be idiomatic.

As you can imagine, I’m against that I believe if try blocks were to be added, they should have a limited use. With combinator methods like map or and_then always being first-choice over try blocks unless there are good reasons.

I don’t think that is an accurate description; 'escape constitutes a magical label that adds to the language. I also think that the form 'escape: { … } is much too subtle for such important control flow and inconsistent with the language at large for the moment; I understand that it is meant to be hidden under a macro; but at this point, you are just eventually reinventing try { … }.

Yes, that is the point Instead of adding exception like error handling piece by piece we give the language the ability to express the semantics as macros,

I also think that the rules for try { … } are pretty well discussed by now; the remaining point of contention seems to be Ok-wrapping.

And this is the kind of problem I’d like to avoid. Either option (conversion or not) could theoretically be the right one. But in difference to ? which had try!, we have no way to gain experience with these semantics on a wider scale. Building the whole thing up with macros to allow the semantics to settle would solve that, and also allow to see what semantics have actual need.

If it turns out there are multiple use-cases that can’t go into a single construct, it might even be preferrable to end up with multiple macros in std in the long run.

[scottmcm]

With combinator methods like map or and_then always being first-choice over try blocks unless there are good reasons.

I don’t think that’s any more true for try/? than it is for async/await.

[phaylon]

I don’t think that’s any more true for try/? than it is for async/await.

Does async/await have a combinator option? I assumed that would have to transform the function into a state machine, which I find to be a different matter than try.

[rpjohnst]

Async started out with only a combinator option- all those methods on Future.

The reason try is different is that it transforms the block into a Result, which doesn’t need any associated code the way a T: Future does.

[scottmcm]

Does async/await have a combinator option?

Absolutely, that’s how it’s written on stable today:

• map: https://docs.rs/futures/0.1/futures/future/trait.Future.html#method.map
• and_then: https://docs.rs/futures/0.1/futures/future/trait.Future.html#method.and_then

[phaylon]

Absolutely, that’s how it’s written on stable today

Then I’d probably use that unless there’s a good reason to go imperative.

I find the fixed pipeline of combinatorial APIs can offer advantages for readability compared to imperative versions. Though I do think that’s more true for dealing with Results than async probably.

I’ll certainly keep using things like foo().and_then(bar).with_context("baz") quite a lot.

[Centril]

I believe that is quite a big constraint.

It seems that I overstated this constraint;

To correct my mistake, I think that try { .. } without Ok-wrapping in proposal A actually would be strictly more powerful than the labeled version because the Try constraint on a try { .. } actually flows from Ok-wrapping in the tail and that without it, requiring Try is more or less a santity-check for the user that isn’t technically necessary.

So the constraint is only technically required iff we have Ok-wrapping.

In any case, if we have Ok-wrapping, then it is possible to modify the semantics of try { .. } after the fact to make use of some sort of 'escape mechanism as a primitive; but I doubt the need will arise.

As you can imagine, I’m against that I believe if try blocks were to be added, they should have a limited use. With combinator methods like map or and_then always being first-choice over try blocks unless there are good reasons.

I’ve come to terms and accepted that Rust is neither a functional nor imperative language. Therefore, I think ? and try { .. } should be considered idiomatic; And you know what, they are kinda like idiom brackets for an with-imperative-features language where you have try { a? + b? } instead of [| a + b |]. So the belief that foo().and_then(bar).with_context("baz") is more functional and that try { a? + b? } somehow imperative is mistaken. With my Haskeller’s hat on, I think that try { a? + b? c? } brings me closer to applicative programming for error handling; and I think that is great; it is even more general than using the heavyweight syntax of .and_then(..).

we have no way to gain experience with these semantics on a wider scale.

We do have nightly; that will allow us to at least test that the semantics we implement works well on a wider number of users than I believe an experimentation-with-crate approach will yield.

If it turns out there are multiple use-cases that can’t go into a single construct, it might even be preferrable to end up with multiple macros in std in the long run.

I think that would be a bad end result; There’s certain value to not having a proliferation of constructs that all users are expected to learn; Having try { .. } in the language makes sure that we “speak the same language”.

[hyeonu]

For throw syntax, maybe we don’t need a special syntax for it. I found that Err(error)? is really convenient for me and already spamming it a lot.

[phaylon]

o the belief that foo().and_then(bar).with_context(“baz”) is more functional and that try { a? + b? } somehow imperative is mistaken.

The terminology doesn’t change the fact that I’ll often prefer chains of map_err, with_context, map, and_then, ok_or_else and such over nested blocks.

Either way, the block vs. method distinction exists in both solutions, so I’m not sure it matters in the context of this proposal.

We do have nightly; that will allow us to at least test that the semantics we implement works well on a wider number of users than I believe an experimentation-with-crate approach will yield.

I’m not sure:

• Experimenters on nightly are a different group than the people experimenting with a stable crate they get to keep.
• You can iterate a lot more quickly on crates.io

More bluntly: Experimentation in core gave us std::error::Error, experimentation on crates.io gave us failure. Imagine if errors had been fixed syntax.

I think that would be a bad end result; There’s certain value to not having a proliferation of constructs that all users are expected to learn; Having try { … } in the language makes sure that we “speak the same language”.

But not without experience what those constructs should be.

We can still end up with try blocks, we just don’t need to hurry for now.

Edit: I would also argue that blocks, labels and breaks are a language we already speak. And we have the chance to figure out the new words with the ones we already have, which is macros on top of extensions of existing syntax.

[Centril]

The terminology doesn’t change the fact that I’ll often prefer chains of map_err, with_context, map, and_then, ok_or_else and such over nested blocks.

You will still be able to do so after… by no means must you adopt my style of writing

The benefit of try { .. } + ? is that other people who prefer the more idiom-bracket-style approach or “rethrow” model will be able to have their needs satisfied as well. A language, be it formal or natural must accomodate many people’s expressive needs.

Experimenters on nightly are a different group than the people experimenting with a stable crate they get to keep.

It’s true; however, I think it is more likely that a crate based approach will reach fewer people with the main experiment than nightly will.

Imagine if errors had been fixed syntax.

That seems unlikely; I don’t think the analogy is apt. I’m not saying we should rush to stabilization of try { .. } or anything, but the semantics have been discussed for at least 4 years now; it seems to me we have some idea of what we’re doing…

But not without experience what those constructs should be.

We can still end up with try blocks, we just don’t need to hurry for now.

I agree; let’s not hurry! I think sufficient experience can be gained from nightly – it is not as if we are starting from scratch; the design space is not that wide open I believe.

Edit: I would also argue that blocks, labels and breaks are a language we already speak. And we have the chance to figure out the new words with the ones we already have, which is macros on top of extensions of existing syntax.

Labeled breaks to non-loops are not even implemented yet, and using labels on loops is not something I’ve seen in code terribly widely.

[phaylon]

It’s true; however, I think it is more likely that a crate based approach will reach fewer people with the main experiment than nightly will.

We can put the macros in std in nightly

That seems unlikely; I don’t think the analogy is apt. I’m not saying we should rush to stabilization of try { … } or anything, but the semantics have been discussed for at least 4 years now; it seems to me we have some idea of what we’re doing…

I’m still not sure if it will end up with auto conversion or not. That doesn’t seem like the semantics have fully been figured out.

I agree; let’s not hurry! I think sufficient experience can be gained from nightly – it is not as if we are starting from scratch; the design space is not that wide open I believe.

It’s not just about this specific design space. It’s about the whole picture of error handling, of what should be idiomatic, what Rusts primary error handling philosophy is going to be and so on. That does seem like a big space to me. try is just one piece of the puzzle.

[rpjohnst]

Then I’d probably use that unless there’s a good reason to go imperative.

There are two really good reasons: loops are really painful to read and write in combinator form, and futures that include self-borrows are impossible to write safely in combinator form.

The same reasons apply to Result and ?. You can trivially write ? in a loop, and you can trivially keep borrows live across ?s. Doing so with combinators may not even be possible, I’ve never seen anyone even try. The only reason it’s tolerated with Futures is that there’s no alternative (yet).

Edit: And there’s a third reason that is more subjective: using a lot of tiny combinator-style functions makes debugging harder, makes debug builds massively slower, and makes builds take longer. I really wish we had a better solution for this in general, but this style just isn’t as well-supported in a lot of ways.

[Centril]

We can put the macros in std in nightly

Then you are back to blessing one experimental model over the others. You could just experiment with language features directly instead.

(Aside: It seems macros became subject to stability all of a sudden; was this change recent?)

I’m still not sure if it will end up with auto conversion or not. That doesn’t seem like the semantics have fully been figured out.

Well; figured out and figured out… People want different things; but the various designs are fairly fleshed out save for the exact details of a Try trait, but that applies to ? as well.

For Result, the possible choices in semantics clear enough to me. So I’d say it is less an issue of what we can do and more an issue of what we should do.

It’s about the whole picture of error handling, of what should be idiomatic, what Rusts primary error handling philosophy is going to be and so on.

Well; we do have ? and an RFC on try { .. } was accepted recently. This should be indicative of what we think is idiomatic, at least to me.

If you’re asking about whether clippy should lint by default against .and_then(..) then it becomes more tricky and we’ll see how contentious that is when we come to it.

[phaylon]

There are two really good reasons: loops are really painful to read and write in combinator form, and futures that include self-borrows are impossible to write safely in combinator form.

Sure, that is a good reason. I even have some examples in the proposal using 'escape for that. But I like to stay combinatorial in iterator chains for example, or if it’s simple one-after-the-other small pieces of code with error modification in-between.

Then you are back to blessing one experimental model over the others. You could just experiment with language features directly instead.

Well, in nightly you could easily support multiple macros for different things, not just a try version.

The advantage of doing it on crates.io is that it works on stable, and will keep working.

@Centril

Well; we do have ? and an RFC on try { … } was accepted recently. This should be indicative of what we think is idiomatic, at least to me.

Personally I feel what is idiomatic should come from community experience, not by try to pre-plan things.

One general note: I think these discussions might be better had when I submit the RFC, otherwise we’re just going to repeat ourselves.

I’m wondering if anyone has any additional use-cases 'escape might solve, or if there’s any technical problems.

[Centril]

Personally I feel what is idiomatic should come from community experience, not by try to pre-plan things.

Fair enough; I’m just making a prediction, but we should certainly let community experience decide this and lint in clippy after some time in stable. This will take considerable time to reach the linting stage.

One general note: I think these discussions might be better had when I submit the RFC, otherwise we’re just going to repeat ourselves.

So it would be great if you noted the technical aspects I brought up wrt. differences in expressive power (and not overstate the case ^,-).

[phaylon]

So it would be great if you noted the technical aspects I brought up wrt. differences in expressive power (and not overstate the case ^,-).

I’m not sure I agree with them yet But I’ll certainly try before it becomes an RFC.

[Centril]

I’m not sure I agree with them yet

Interesting; Specifically what parts are wrong if so?

[phaylon]

Because type-based jump targeting, e.g. full blown real life exceptions, I feel is way outside of Rust’s error handling philosophy. To argue that try is more powerful because try! can’t do that seems out of scope to me. Additionally, same as with 'escape if Rust were to gain a general not-error-related facility to do this, macros once again can be used to implement it.

“Finding an upscope return position by type instead of current control flow” is not a feature that has to be tied to try. Given this, and that I’m not aware any of that has ever been planned, or is somewhere planned for the future, I don’t think we can attribute that power to either macros or syntax yet.

[Centril]

Because type-based jump targeting, e.g. full blown real life exceptions, I feel is way outside of Rust’s error handling philosophy.

Separating the factual and subjective

I think you need to separate two things:

• Is something technically possible, equal in power or more powerful? [this is factual and testable]
• Is something desirable to have in a language? [this is subjective, and based on desirability]

From a factual POV

try { .. }, without Ok-wrapping, is strictly more powerful because it gives you more possibilities than 'escape does.

This means that 'escape can’t support type-based jump targeting since it is based on syntax alone, and that limits our design freedom.

This also means that it subsumes everything that 'escape can do wrt. library based experimentation with macros and whatnot.

From a subjective POV

Some possibilities may not be desirable… (Aside: type-based jump targeting is not how Java does exceptions, and it can’t escape the function boundary, so it is not unwinding based or “full blown exceptions”.)

You might think that we should limit our design freedom in some aspects (as you do with type-based jump targeting); and I agree that this is acceptable. My view is that we should limit freedom wrt. Ok-wrapping because Ok-wrapping is beneficial. I understand you will disagree with this point of view.