[rfc] feature to facilitate exception-free code

[tx46]

background: https://forum.rescript-lang.org/t/proposing-new-syntax-for-zero-cost-unwrapping-options-results/6227

with this feature, we will be able to do early returns and propagate errors as they arise, kind of like rust's question mark-operator. this has the same sort of effect as throwing an exception in that it will bubble up through all let? assignments until the error is handled somehwere, just like exceptions.

the line between exceptions and errors thus blurs, basically resulting in two different syntaxes to do roughly the same thing, but requiring different handling methods somewhere on the caller's end.

the one place where this is not trivial to address is on the ffi boundary, where external functions may throw for various (and even unknown/unexpected) reasons, requiring you to handle exceptions in your rescript code.

as a suggestion to prevent exceptions and facilitate exception-free code (instead using Errors and let?s), some way of "wrapping" an ffi binding should be provided, e.g.:

@toResult
external somethingThatCouldThrow: string => string = "somethingThatCouldThrow"

// the above would be sugar for:
// let somethingThatCouldThrow: string => result<string, JsExn.t>
// it also needs to be able to handle `promise`s:
external somethingThatCouldThrowAsync: string => promise<string> = "somethingThatCouldThrowAsync"

// let somethingThatCouldThrowAsync: string => promise<result<string, JsExn.t>>

here, somethingThatCouldThrow would be wrapped with a try-catch that catches all errors and returns them as Error<JsExn.t>

this would facilitate static analysis for unhandled Error cases, as well as allow us to write exception-free code, moving towards a sane, predictable and exhaustive handling of errors (again, think rust).

we should also think through how this would apply to async ffi. the external call would have to be awaited inside the try-catch. what if it spawns another unawaited promise internally (global unhandled rejection)? does it make the rejection case redundant, or should Error result in rejection with the error (then we won't be able to switch on the result in .then)?

let's discuss this and see if it makes sense and how it could be implemented.

[zth]

Async should be fine, just a matter of detecting if the return is a promise and if so await. If we emit wrapper code like this (this could be the transformed code from using @toResult):

@toResult
external somethingThatCouldThrow: string => string = "somethingThatCouldThrow"
let somethingThatCouldThrow = (v) => switch somethingThatCouldThrow(v) {
| exception e => Error(e)
| ok => Ok(ok)
}

Then making it async is easy, because switch await with an exception branch will handle promise rejections (which I assume is what we'd track here):

@toResult
external somethingThatCouldThrowAsync: string => promise<string> = "somethingThatCouldThrowAsync"
let somethingThatCouldThrowAsync = async (v) => switch await somethingThatCouldThrow(v) {
| exception e => Error(e)
| ok => Ok(ok)
}

Some questions that pop into mind from me:

• Is exceptions the only thing we'd want to track? Should we consider handling null/option returns to be Ok/Error as well?
• We should consider emitting errors as polyvariants so we can promote that pattern, e.g let somethingThatCouldThrow: string => result<string, [#JsExn(JsExn.t)]>

[tx46]

i think @toOption would make sense for functions that return a value or null/undefined (both null and undefined -> None).

good point regarding error polyvariants. what if you know the exceptions that the function could throw, should you be able to list them to type the errors that can be returend? i.e. @toResult([#MyError1, #MyError2])

[zth]

The equivalent of @toOption already exists actually: https://rescript-lang.org/syntax-lookup#return-decorator

Re mapping errors, I guess in theory that could be a useful thing, but as always it becomes the question of how those errors are shaped in runtime in the underlying API. They'll need remapping. Probably something easier to just do in user land as a mapping function.

[zth]

Anyone else have ideas/opinions here?

@tsnobip @fhammerschmidt @cknitt @nojaf @cometkim @jderochervlk

[tsnobip]

being able to wrap them in a (customizable?) polymorphic variant would be nice indeed!

[fhammerschmidt]

For consistency, could it be @return(result) or similar?

[nojaf]

Overall, I'm a fan of the idea. I can't quite put my finger on it yet, but this proposal feels like a part of a larger narrative. It would be great if we could flesh out some real example cases. It also makes me think about Promise.try in some way.

[cometkim]

I'm concerned about comparing this to Rust's ? syntax. While it looks similar, it's an entirely different feature. Rust's ? leverages their type system (trait bounds) to handle the actual type/runtime conversion. We can't solve the problem in the same way because we don't have an equivalent.

[zth]

I'm concerned about comparing this to Rust's ? syntax. While it looks similar, it's an entirely different feature. Rust's ? leverages their type system (trait bounds) to handle the actual type/runtime conversion. We can't solve the problem in the same way because we don't have an equivalent.

This is a reflection on let?, right, not on @toResult/@return(result)?

[cometkim]

I'm not sure I understand the proposal correctly, but it seems like neither side knows how to handle error types, unlike Rust. Personally, I don't think it's useful for mid-large size codebases. It feels like something to be avoided.

Also, spawning promises at runtime is not cheap: constructors + GC pressure + delayed microtasks.

[tx46]

I'm not sure I understand the proposal correctly, but it seems like neither side knows how to handle error types, unlike Rust. Personally, I don't think it's useful for mid-large size codebases. It feels like something to be avoided.

Also, spawning promises at runtime is not cheap: constructors + GC pressure + delayed microtasks.

maybe i'm confusing things here but i don't understand your concerns with regard to let? nor to this proposal. first off, let? functionally seems to be close to what rust does (e.g., assign or early-return error). secondly, this proposal has nothing to do with spawning promises, it's about wrapping promises already being spawned in a try-catch construct and returning an Error in the catch-branch, thus turning a value/exception into a Result.

this proposal, unless i'm missing something, has nothing to do with the size of codebases, but is just sugar for turning exceptions into Results on the ffi boundary.

[cometkim]

Using the result type is not much worth if it doesn't deal with errors correctly.

Rust actually covers it "explicitly". Is only allowed when the compiler understands exactly how an error is converted into the returnng error type and is not a simple unwrapping sugar.

But the let? proposal feels like using anyhow crate everywhere.

[zth]

Maybe concrete examples on what you think is problematic would help @cometkim , I don't really follow the point you're making.

Either way, let's keep this issue about @return(result) (opt-in catching exceptions and turning them into results) and add any feedback to let? to that forum thread instead. While somewhat related they're actually separate things and does not depend on eachother.

[cknitt]

I like the general idea. I think that in any case, the return type in the type definition should reflect the actual return type, which is not the case in the originally proposed version where the return type is just string:

@toResult
external somethingThatCouldThrow: string => string = "somethingThatCouldThrow"

For consistency, could it be @return(result) or similar?

Agreed, as we already have

@return(nullable)
external someFunc: unit => option<string> = "someFunc"

We could for example support the following, where the wrapping in a promise is detected automatically:

@return(nullable)
external someFunc: unit => option<string> = "someFunc"

@return(nullable)
external someFunc: unit => promise<option<string>> = "someFunc"

@return(result)
external someFunc: unit => result<string, JsExn.t> = "someFunc"

@return(result)
external someFunc: unit => promise<result<string, JsExn.t>> = "someFunc"

// or maybe
@return(result)
external someFunc: unit => result<string, [#JsExn(JsExn.t)]> = "someFunc"

@return(result)
external someFunc: unit => promise<result<string, [#JsExn(JsExn.t)]>> = "someFunc"