cmeeren / cvdm.errorhandling Goto Github PK

We might want to go away from the Async<Result<_,_>> overloads and instead use a dedicated wrapper type:

Type AsyncResult<'a,'b> = AR of Async<Result<'a,'b>>

This is similar to how Chessie works. The main benefit is to avoid having to add type annotations with let! and use! (dotnet/fsharp#4472).

Pros:

• No more need for type annotations on let! bindings whenever the right-hand side is Async<Result<_,_>>
• No more need for type annotations after use! bindings (same as let!, but slightly more cumbersome since use! doesn't support type annotations on the binding, i.e. use! (foo: MyDisposableType) = ... is invalid and type annotations must be added later where it's first used)
• No more trickery with extension overloads (I don't really have a problem with this in and of itself)

Cons:

• Breaking change (not important, we're still at 0.x and the library is less than a week old)
• Right hand sides having type Async<Result<_,_>> must be wrapped in AR by appending |> AR (though this is not very likely to happen, since such right-hand sides will likely be the result of another asyncResult CE and already be of type AsyncResult<_,_>)
• When using an AsyncResult in an async CE (in order to get the result, or at high levels of the app), it must be unwrapped to Async<Result<_,_>>

This is awesome. Great job.
One suggestion...

type AsyncResult<'ok, 'error> = Async<Result<'ok, 'error>>

Just throwing out an idea, it could be interesting to support the task {} CE from TaskBuilder.fs, adding a taskResult {} CE and module which mirror asyncResult {}.

I'm unlikely to personally use such a feature, but it seems there's some demand.

With the Fable compatibility brought in by #8 by @danyx23 we should ideally have some kind of test to ensure the Fable compatibility is not broken in the future. I don't use Fable myself, so I'm not sure whether this is feasible or how to do it.

We are using the SAFE stack and it would be great if we could use this nuget package also on the frontend code that is compiled with Fable. Since fable transpiles to Javascript from F# source code, Nuget packages that are to be used by Fable need to be compiled in a way that includes the F# source code in the nuget package. Would you be open to a pull request that introduces the paket nuget package manager to this repo and sets up the nuget package to be used with Fable?

Hi! Thanks for this really nice library! We just had a really weird problem around upgrading from 0.4.0 to 0.5.1 that others might run into as well so I wanted to document it here.

Our setup was a Library that was using the Cvdm asyncResult and an executable that was referencing the library and also using Cvdm asyncResult itself. We use Paket to manage dependencies. After upgrading and recompiling, we all of a sudden had this error at runtime (compile worked fine):

Unhandled Exception: System.TypeInitializationException: The type initializer for '<StartupCode$Registry>.$Edelweiss.Registry.Main' threw an exception. ---> System.MissingMethodException: Method not found: 'AsyncResultBuilder Cvdm.ErrorHandling.Helpers.get_asyncResult()'.

On the library, the version constraint for Cvdm.ErrorHandling was set to ~> 0 as our intent was that newer major versions should be fine.

I don't have the time right now to investigate exactly what was happening here, but after recompiling the library and the app with 0.5.1 the weird runtime error went away. I think there is nothing this library can do at this point, but maybe you can leave this ticket open for a little while so people running into this problem can find it?

For the time being Cvdm.ErrorHandling will continue to be updated/supported, but I'd just like to mention that there are efforts ongoing to merge Cvdm.Errorhandling into FsToolkit.ErrorHandling, see demystifyfp/FsToolkit.ErrorHandling#3. No time frame is available.

The following code should catch errors at the try-with block level of the asyncResult but instead the exception is not caught and the exception bubbles up (potentiall crashing the application)

let throwingFn() =
    async {
        failwith "was asked to throw"
    }

let catchingFn() =
    asyncResult {
        try
            do! throwingFn()
        with ex ->
            printfn "Got exn: %O" ex
    }

I'll send a PR to fix this shortly

When investigating #11 I was wondering if asyncResult.Delay must also delegate to Delay to keep the cancellationtoken semantics etc of the async type. I'm not familiar enough with CEs, do you know if this might be necessary?