New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support "Raise" keywords in computation expressions #613

Open
eiriktsarpalis opened this Issue Oct 4, 2017 · 6 comments

Comments

Projects
None yet
4 participants
@eiriktsarpalis

eiriktsarpalis commented Oct 4, 2017

Support "Raise" keywords in computation expressions

I propose we add support for a Raise : exn -> M<'T> computation expression method. This would address two issues:

  1. Provide a native way of throwing inside computation expressions: we could write raise! Exception() instead of return raise Exception().

  2. Solve an issue related to desugaring partial exception handling code. Currently the handler of try ... with pattern exn -> cexpr desugars into fun exn -> if pattern exn then cexpr else raise exn. This results in a) loss of stacktrace info and b) phantom breaks happening when debugging an application. The presense of a Raise() builder could allow the compiler to desugar a handler into fun exn -> if pattern exn then cexpr else builder.Raise exn which provides a finer grain of control to the computation expression author.

Pros and Cons

The advantages of making this adjustment to F# are stated above.

The disadvantages of making this adjustment to F# are confusion among beginners on the differences between return raise e and raise! e

Extra information

Estimated cost (XS, S, M, L, XL, XXL): M

Affidavit (please submit!)

Please tick this by placing a cross in the box:

  • This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
  • I have searched both open and closed suggestions on this site and believe this is not a duplicate
  • This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it.

Please tick all that apply:

  • This is not a breaking change to the F# language design
  • I or my company would be willing to help implement and/or test this
@pblasucci

This comment has been minimized.

Show comment
Hide comment
@pblasucci

pblasucci commented Oct 4, 2017

+1

@dsyme

This comment has been minimized.

Show comment
Hide comment
@dsyme

dsyme Oct 4, 2017

Collaborator

The advantages of making this adjustment to F# are stated above.

I think there are more advantages than listed - notably performance? The exception gets into the computation without actually being caught and re-raised

Collaborator

dsyme commented Oct 4, 2017

The advantages of making this adjustment to F# are stated above.

I think there are more advantages than listed - notably performance? The exception gets into the computation without actually being caught and re-raised

@eiriktsarpalis

This comment has been minimized.

Show comment
Hide comment
@eiriktsarpalis

eiriktsarpalis Oct 4, 2017

Yes, that too.

eiriktsarpalis commented Oct 4, 2017

Yes, that too.

@dsyme

This comment has been minimized.

Show comment
Hide comment
@dsyme

dsyme Oct 4, 2017

Collaborator

I like this idea, I'd like to see a prototype. I don't see why we wouldn't do this. Except perhaps that it might lead to expectations that there is a failwith! and failwithf! and so on? Currently raise is just a function after all

Collaborator

dsyme commented Oct 4, 2017

I like this idea, I'd like to see a prototype. I don't see why we wouldn't do this. Except perhaps that it might lead to expectations that there is a failwith! and failwithf! and so on? Currently raise is just a function after all

@vasily-kirichenko

This comment has been minimized.

Show comment
Hide comment
@vasily-kirichenko

vasily-kirichenko Oct 5, 2017

Can it be implemented with a custom operation?

vasily-kirichenko commented Oct 5, 2017

Can it be implemented with a custom operation?

@dsyme

This comment has been minimized.

Show comment
Hide comment
@dsyme

dsyme Nov 16, 2017

Collaborator

@eiriktsarpalis Re this:

Can it be implemented with a custom operation?

Have you tried that? thanks

Collaborator

dsyme commented Nov 16, 2017

@eiriktsarpalis Re this:

Can it be implemented with a custom operation?

Have you tried that? thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment