4

我在调用恰好为空的嵌套异步时偶然发现了一个问题。引发了异常，但无法使用异步工作流提供的任何正常异常处理方法捕获它。

以下是重现问题的简单测试：

[<Test>]
let ``Nested async is null with try-with``() = 

    let g(): Async<unit> = Unchecked.defaultof<Async<unit>>

    let f = async {
            try
                do! g()
            with e ->  
                printf "%A" e
    }

    f |> Async.RunSynchronously |> ignore

这导致以下异常：

System.NullReferenceException : Object reference not set to an instance of an object.
at Microsoft.FSharp.Control.AsyncBuilderImpl.bindA@714.Invoke(AsyncParams`1 args)
at <StartupCode$FSharp-Core>.$Control.loop@413-40(Trampoline this, FSharpFunc`2 action)
at Microsoft.FSharp.Control.Trampoline.ExecuteAction(FSharpFunc`2 firstAction)
at Microsoft.FSharp.Control.TrampolineHolder.Protect(FSharpFunc`2 firstAction)
at Microsoft.FSharp.Control.AsyncBuilderImpl.startAsync(CancellationToken cancellationToken,     FSharpFunc`2 cont, FSharpFunc`2 econt, FSharpFunc`2 ccont, FSharpAsync`1 p)
at Microsoft.FSharp.Control.CancellationTokenOps.starter@1121-1.Invoke(CancellationToken     cancellationToken, FSharpFunc`2 cont, FSharpFunc`2 econt, FSharpFunc`2 ccont, FSharpAsync`1 p)
at Microsoft.FSharp.Control.CancellationTokenOps.RunSynchronously(CancellationToken token, FSharpAsync`1 computation, FSharpOption`1 timeout)
at Microsoft.FSharp.Control.FSharpAsync.RunSynchronously(FSharpAsync`1 computation, FSharpOption`1 timeout, FSharpOption`1 cancellationToken)
at Prioinfo.Urkund.DocCheck3.Core2.Tests.AsyncTests.Nested async is null with try-with() in SystemTests.fs: line 345

我真的认为在这种情况下应该捕获异常，或者这真的是预期的行为吗？（我正在使用 Visual Studio 2010 Sp1 进行记录）

此外，Async.Catch并Async.StartWithContinuations表现出与这些测试用例所展示的相同的问题：

[<Test>]
let ``Nested async is null with Async.Catch``() = 

    let g(): Async<unit> = Unchecked.defaultof<Async<unit>>

    let f = async {
                do! g()
            }

    f |> Async.Catch |> Async.RunSynchronously |> ignore


[<Test>]
let ``Nested async is null with StartWithContinuations``() = 

    let g(): Async<unit> = Unchecked.defaultof<Async<unit>>

    let f = async {
                do! g()
            }

    Async.StartWithContinuations(f
                                , fun _ -> ()
                                , fun e -> printfn "%A" e
                                , fun _ -> ())

似乎在工作流构建器的绑定方法中引发了异常，我的猜测是，因此绕过了正常的错误处理代码。对我来说，这看起来像是异步工作流实现中的一个错误，因为我在文档或其他地方没有发现任何表明这是预期行为的内容。

在大多数情况下，我认为这很容易解决，所以至少对我来说这不是一个大问题，但这有点令人不安，因为这意味着你不能完全相信异步异常处理机制能够捕获所有异常.

编辑：

经过一番思考，我同意kvb。Null asyncs 不应该真的存在于普通代码中，并且只有在你做一些你可能不应该做的事情（例如使用 Unchecked.defaultOf）或使用反射来产生值（在我的情况下它是一个涉及的模拟框架）时才能真正产生. 因此，这不是一个真正的错误，而是更多的边缘情况。

4

2 回答 2

5

我不认为这是一个错误。顾名思义，Unchecked.defaultof<_>它不检查它产生的值是否有效，Async<unit>也不支持null作为正确的值（例如，如果您尝试使用，请参阅消息let x : Async<unit> = null）。 Async.Catch等旨在捕获在异步计算中引发的异常，而不是由于在编译器背后偷偷摸摸并创建无效的异步计算而导致的异常。

于 2012-01-19T10:48:43.070 回答
4

我完全同意 kvb - 当您使用 初始化一个值时Unchecked.defaultOf，这意味着使用该值的行为可能是未定义的，因此这不能被视为错误。实际上，您不必担心它，因为您永远不应该获得类型null的值Async<'T>。

添加更多细节，无法处理异常，因为翻译如下所示：

async.TryWith
  ( async.Bind ( Unchecked.defaultof<_>, 
                 fun v -> async { printfn "continued" } ), 
    fun e -> printfn "%A" e)

在启动返回的工作流之前Bind从方法中引发异常（它发生在您调用 之后，因为工作流是使用 包装的，但它发生在工作流执行之外）。如果您想处理此类异常（由错误构造的工作流引起），您可以编写一个运行工作流并处理在执行之外抛出的异常的版本：BindRunSynchronouslyDelayTryWith

let TryWith(work, handler) = 
  Async.FromContinuations(fun (cont, econt, ccont) ->
    try
      async { let! res = work in cont res }
      |> Async.StartImmediate
    with e -> 
      async { let! res = handler e in cont res } 
      |> Async.StartImmediate )

然后你可以处理这样的异常：

let g(): Async<unit> = Unchecked.defaultof<Async<unit>> 
let f = 
    TryWith
      ( (async { do! g() }),
        (fun e -> async { printfn "error %A" e }))
f |> Async.RunSynchronously
于 2012-01-19T15:05:46.160 回答