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

[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.

[phaylon]

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

I agree that 'escape by itself can not do this. But who says break for example could never learn this? So while strictly try {...} might be able to aquire this, so can a macro based solution.

And it’s not like this isn’t also working in the other direction: A macro can be shadowed, making it easy for a user to add, for example, tracing log output to all of them if they want. Shadowing builtin syntax would require a fully new feature.

[Centril]

I agree that 'escape by itself can not do this. But who says break for example could never learn this?

Because if you have break 'escape expr as the basis on which your macros are built upon, then you have locked in the jump target, and it can’t be anywhere else.

Using break expr without any sort of label is also problematic because of all the interactions with loops et al. which makes it all less expressive (because throw expr and expr? could disambiguate between loops and try { .. } whereas break without a label can’t…).

And it’s not like this isn’t also working in the other direction: A macro can be shadowed, making it easy for a user to add, for example, tracing log output to all of them if they want. Shadowing builtin syntax would require a fully new feature.

This can still be done atop of try { .. } with a macro that you can then swap out, or by defining a different effect carrier than Result which has richer effects (this seems the more robust solution to change/extend the effect carrier type, especially if we get HKTs and with we can then define monad transformer-like structures…).

[phaylon]

Because if you have break 'escape expr as the basis on which your macros are built upon, then you have locked in the jump target, and it can’t be anywhere else.

The macros can be adjusted. try { ... } and throw as proposed doesn’t offer the funcionality either.

This can still be done atop of try { … } with a macro that you can then swap out, or by defining a different effect carrier than Result which has richer effects (this seems the more robust solution to change/extend the effect carrier type, especially if we get HKTs and with we can then define monad transformer-like structures…).

Yeah, but I’d have to swap out the try for the macro. With macros I can go to the source defining it, take it to my project, adjust it and all of them are going to be adjusted accordingly. Any type API based solution would also be more limited than AST based adjustments with macros.

But we’re getting really off-topic here again. I’ll make sure to add a clarification that the flexibility of 'escape concerns the discussed part of error handling functionality.

[Centril]

The macros can be adjusted. try { … } and throw as proposed doesn’t offer the funcionality either.

Unless the macro has access to a primitive mechanism like try { .. } it can’t be adjusted in that way.

Yeah, but I’d have to swap out the try for the macro.

What I’m saying is that you’d define the macro as an abstraction in terms of try; when you have break 'try expr, then you get both the syntax based mechanism AND the type based mechanism.

[phaylon]

Yes, I’m talking about the feature of live-swapping parts of existing code.

[Soni]

Rust std has lots of methods called try_fold try_unwrap try_into etc.

Also, macros can add type assertions, as they can expand to, say, {let x = $arg; assert_try(&x); x}, where assert_try(&x) is fn assert_try<T: Try>(_x: &T) {}.

[phaylon]

I’ve now made an RFC out of the idea.

One big change is that the RFC uses escape {} blocks instead of 'escape: {} labels due to problems migrating existing code using labels and ?.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.