我目前正在尝试将相当数量的现有同步代码移植到WinRT.
作为其中的一部分,我遇到了现有代码的问题,希望某些操作是同步的 – 例如用于文件I / O.
为了使这个现有代码适应WinRT中的IAsyncOperation样式API,我使用了一种使用扩展方法包装IAsyncOperation的技术,如：
- namespace CirrIoUs.MvvmCross.Plugins.File.WinRT
- {
- public static class WinRTExtensionMethods
- {
- public static TResult Await<TResult>(this IAsyncOperation<TResult> operation)
- {
- var task = operation.AsTask();
- task.Wait();
- if (task.Exception != null)
- {
- // TODO - is this correct?
- throw task.Exception.InnerException;
- }
- return task.Result;
- }
- }
- }
从MvvmCross WinRT ExtensionMethods开始 – 使用与IAsyncAction类似的方法
这些包装器似乎有效 – 它们允许我在同步代码中使用Async方法,如：
- public IEnumerable<string> GetFilesIn(string folderPath)
- {
- var folder = StorageFolder.GetFolderFromPathAsync(ToFullPath(folderPath)).Await();
- var files = folder.GetFilesAsync().Await();
- return files.Select(x => x.Name);
- }
我知道这并不是真正符合WinRT的精神;但我希望这些方法通常只能在后台线程上调用;我写这篇文章的目的是让我的代码跨平台兼容 – 包括那些尚未支持await-async的平台和/或尚未准备好跳转的开发人员.
所以……问题是：使用这种类型的代码我运行的风险是什么？
解决方法
首先,我认为您的方法可以改写为：
- public static TResult Await<TResult>(this IAsyncOperation<TResult> operation)
- {
- return operation.AsTask().Result;
- }
如果任务尚未完成,则调用结果将同步等待.如果失败,它将抛出AgreggateException.我认为像你一样抛出InnerException是个坏主意,因为它会覆盖异常的堆栈跟踪.
关于你的实际问题,我认为使用Wait()和异步代码的最大危险是死锁.如果你在UI线程上启动一些内部使用await的操作,然后在同一个线程上使用Wait()等待它,你将遇到死锁.
如果你没有在UI线程上等待,那么这并不重要,但如果可能的话,你仍然应该避免它,因为它违背了整个异步的想法.
