Using task instead of async, and offering query functions that fail hard instead of returning Result

I am using the library for accessing data for a Giraffe web application, and it’s a pleasure to use so far! However, two things come to mind:

1. As Giraffe switched to https://github.com/rspeele/TaskBuilder.fs some time ago, it would be nice to also get tasks out of it.
2. In the context of a mobile app I would always prefer Result, however, for a web app I’d like to fail it hard and immediately -> throw exceptions.

So what I am doing right now is that:

module Sql =
    let throwOrReturn (result: Async<Result<'a, exn>>) =
        task {
            let! result = result |> Async.StartImmediateAsTask
            match result with
            | Ok result -> return result
            | Error exn -> return raise exn
        }

module FooRepository =
    let all =
        connect()
        |> Sql.query "..."
        ...
        |> Sql.throwOrReturn

I evaluate the result directly and either return the value or raise the exception. That’s not perfect for many reasons, but the only workaround that comes to mind right now.

I also tried to make the adjustments as suggested myself, but as some things are private I cannot extend the existing library as I wish I could:

I see that switching from async to task would be a massive breaking change. Maybe it would be possible to add it as as second option. As far as I can see, the parts within async { ... } would also work in task { ... }, so it wouldn’t even require code duplication. Update: Forget about this, that’s probably not going to work.

The same goes for functions that do not return Result. Those could be used inside of the existing ones and a try ... with block.

What do you think?

[Zaid-Ajaj]

It might be worth it for the library to consider using ExceptionDispatchInfo.Capture as a way to handle exceptions so capturing the stacktrace remains accurate when a consumer throws it.

@TheAngryByrd Smells like a PR, doesn’t it? 😄 Would really appreciate it if you send one since we are still using Result in the Npgsql.FSharp namespace

[Zaid-Ajaj]

Resolved as of v3.12.3