Can we use Try/Catch Within QueuedTask.Run()

Question

Can we use Try/Catch within QueuedTask.Run()?

I have feeling that Try/Catch should be outside QueuedTask.Run() but I don't have reason for that. Please clarify whether to keep in or out of 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)));
    }
}

Please elobrate on your feeling. Maybe you have actualy a different question? That said agree with above comment. — Christian Gollhardt, Jul 18 '18 at 00:19
I am just thinking whether to use Try Catch outside QueuedTask.Run() or inside. How does this make a difference in execution? Please help here to understand difference keeping it outside or inside. — Sgupta, Jul 18 '18 at 00:23
The only possible issue I see is calling DialogService.ShowPrompt() from a background thread. If it handles that correctly, then you're fine. — glenebob, Jul 18 '18 at 00:28
I am suggesting you literally try it out. Move the `try catch`. Purposely throw an exception. Compare how the two scenarios act. To be clear **I know what will happen**. I am trying to teach you to fish. — mjwills, Jul 18 '18 at 00:49
Thanks but i just left workplace. It would be great if u can let me know “What will happen” as you already know being an expertise — Sgupta, Jul 18 '18 at 00:54
You can't interact with any UI element from a non-UI thread. Showing a dialog is then out if you're in a task. — Enigmativity, Jul 18 '18 at 05:01
Also, don't do `catch (Exception ex)` - it's a bad anti-pattern. You should only ever catch **specific** exceptions that you can **meaningfully** handle. — Enigmativity, Jul 18 '18 at 05:02

Christian Gollhardt · Answer 1 · 2018-07-18T00:51:14.300

If you do not have a reason to handle it outside, then it is okay to handle it inside. You should always handle exceptions as soon as you can handle it correctly. So I would go for inside.

I have no domain knowledge about ArcGIS, but if QueuedTask.Run can throw it's own exceptions (exception which are not generated by your delegate), you wouldn't catch them this way. However, you should handle that seperate anyway.

Also you need to consider, QueuedTask.Run seems like an async operation. So to be able to catch any Exception you need to await it before. If you can't, you definitive need to catch it inside.

So the definitive answer: It depends. It could also be a context decission as glenebob commented:

The only possible issue I see is calling DialogService.ShowPrompt() from a background thread.

On a side note: You should use catch all exceptions only as a last resort. See this.

Can we use Try/Catch Within QueuedTask.Run()

1 Answers1