我们可以在 QueuedTask.Run() 中使用 Try/Catch答案

【问题标题】：Can we use Try/Catch Within QueuedTask.Run()我们可以在 QueuedTask.Run() 中使用 Try/Catch
【发布时间】：2018-12-25 18:30:49
【问题描述】：

我们可以在QueuedTask.Run() 中使用 Try/Catch 吗？

我觉得 Try/Catch 应该在 QueuedTask.Run() 之外，但我没有理由这样做。请说明是留还是留QueuedTask.Run()

public ICommand CmdEdit
{
    get
    {
        return _cmdEdit ?? (_cmdEdit = new RelayCommand(() =>
        {
            QueuedTask.Run(() =>
            {
                try
                {
                    if (_selectedObj != null && SelectedObjs.Count() == 1)
                    {
                        OnEditObj(_selectedObj);
                    }
                }
                catch (Exception ex)
                {
                    DialogService.ShowPrompt(ex, null, DialogServiceMessage.Message_EditError, DialogServiceCaption.Caption_Exception, DialogServiceButtons.Ok, DialogServiceIcon.Exclamation);
                    OneGeo.ExceptionLogger.EventLogger.Log(ex);
                }
            });
        }, () => (_selectedObj != null && _selectedObjs.Count() == 1)));
    }
}

【问题讨论】：

我觉得很好。
请详细说明您的感受。也许你实际上有一个不同的问题？那就是同意上面的评论。
我只是在考虑是在 QueuedTask.Run() 外部还是内部使用 Try Catch。这对执行有何影响？请在此处帮助了解将其放置在外部或内部的区别。
我看到的唯一可能的问题是从后台线程调用 DialogService.ShowPrompt()。如果它处理正确，那么你很好。
我建议您尝试一下。移动try catch。故意抛出异常。比较这两种情况的行为方式。说清楚我知道会发生什么。我正在教你钓鱼。

标签： c# .net arcgis arcgis-runtime

【解决方案1】：

如果你没有理由在外面处理它，那么在里面处理它是可以的。只要您能正确处理异常，您就应该始终处理它。所以我会进去。

我没有关于 ArcGIS 的领域知识，但是如果 QueuedTask.Run 可以抛出它自己的异常（不是由您的委托生成的异常），您就不会以这种方式捕获它们。但是，无论如何您都应该单独处理。

您还需要考虑，QueuedTask.Run 似乎是 async 操作。因此，为了能够捕获任何异常，您需要先await 它。如果你不能，你肯定需要抓住它。

所以确定的答案是：视情况而定。正如glenebob 评论的那样，这也可能是一个上下文决定：

我看到的唯一可能的问题是从后台线程调用DialogService.ShowPrompt()。

附带说明：您应该仅将捕获所有异常作为最后的手段。见this。

【讨论】：