Back to Questions
3.8k
views3
comments
raise exception from async workflow causes type inference to fail (falls back to unit)
f#workflowsasyncasynchronous

Consider the following code. This not what I'm trying to do; it's the simplest example I could come up with that demonstrates the problem.

1

open System let wrapExceptionAsync<'TinnerExn, 'TouterExn when 'TinnerExn :> exn and 'TouterExn :> exn> (getValue : Async<'a>) (wrap : 'TinnerExn -> 'TouterExn) : Async<'a> =   async {      try         return! getValue      with      | :? 'TinnerExn as inner -> raise(wrap(inner))   } let dowrapAsync denominator =    let getValue = async { return 1 / denominator }   let wrap = fun (inner : DivideByZeroException) -> new ApplicationException("0 is not a valid value for denominator",inner)   wrapExceptionAsync getValue wrap try   Console.WriteLine(Async.RunSynchronously(dowrapAsync 0))with| e ->   Console.WriteLine(e) Console.ReadLine() |> ignore

It doesn't compile. It gives a warning saying "This construct causes code to be less generic than indicated by the type annotations. The type variable 'a has been constrained to be type 'unit'." and an error, "Type mismatch. Expecting a Async<unit> but given a Async<int> The type 'unit' does not match the type 'int'".

Now consider this code, which is exactly the same thing, but without the asynchronous workflows:

1

open System  let wrapException<'a, 'TinnerExn, 'TouterExn when 'TinnerExn :> exn and 'TouterExn :> exn> (getValue : unit -> 'a) (wrap : 'TinnerExn -> 'TouterExn) : 'a =try   getValue()with| :? 'TinnerExn as inner -> raise(wrap(inner)) let dowrap denominator =    let getValue() = 1 / denominator   let wrap = fun (inner : DivideByZeroException) -> new ApplicationException("0 is not a valid value for denominator",inner)   wrapException getValue wrap try   Console.WriteLine(dowrap 0)with| e ->   Console.WriteLine(e) Console.ReadLine() |> ignore

It compiles without any problems and works as expected. Is this a bug with computation expressions? Is there a workaround (that is, simultaneously raising exceptions from async workflows and returning something other than unit)

.

Short answer for now: put "return" (or "return!", either works) in front of "raise" in the async case and it will compile. (I am unclear if this is a bug.)

By on 12/17/2009 1:58 PM ()

Ok, yeah. The language behaves like this:

1
2
3
4
5
6
7
8
9
10

 

// returns Async<unit>
let F() =
    async { failwith "boom" }

// returns Async<'a>
let G() =
    async { return failwith "boom" }

Basically in order for an always-raises-an-expression value to get generalized in a computation, you need to add a "return", otherwise you always get the "unit" type inferred.

By on 12/17/2009 2:09 PM ()

Works great. Thank you!

By on 12/17/2009 6:04 PM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper