What is the difference between declaring with (async and await) vs. not declaring them at all?

GyanendraGurung

I have removed the async and await functionalities from following code (copied from GeoprocessingExecuteAsync example) and it still works fine. My question is are they both correct (because i am not seeing any difference in the response of the system, i.e. with QueuedTask implementation, ArcGISPro is responsive in both cases? 

Many thanks in advance. 

The original code:

1. protected override async Task<bool> OnSketchCompleteAsync(Geometry geometry)  
2. {  
3.     var valueArray = await QueuedTask.Run(() =>  
4.     {  
5.         var g = new List<object>() { geometry, };  
6.         // Creates a 8000-meter buffer around the geometry object  
7.         // null indicates a default output name is used  
8.         return"8000 Meters");  
9.     });  
10.   
11.     await Geoprocessing.ExecuteToolAsync("analysis.Buffer", valueArray);  
12.     return true;  
13. }  

and the modified code (async and await removed):

1. protected override Task<bool> OnSketchCompleteAsync(Geometry geometry)  
2. {  
3.     var something = QueuedTask.Run(() =>  
4.     {  
5.         var g = new List<object>() { geometry, };  
6.         // Creates a 8000-meter buffer around the geometry object  
7.         // null indicates a default output name is used  
8. "8000 Meters");  
9.         Geoprocessing.ExecuteToolAsync("analysis.Buffer", valueArray);  
10.         return true;  
11.     });              
12.     return something;  
13. }  

John_Jones

To the caller of this function they see different results in that the first version the returned Task isn't complete until the GP tool is finished executing, while in the second version the Task is complete as soon as the GP tool has been scheduled for execution (not yet complete).  ExecuteToolAsync doesn't particularly care whether it is called on the UI thread or the background thread but in the second version since the Task it returns is never either awaited or returned to the caller it is never observed.  If this Task were to throw an exception it would not be observed until the Task was garbage collected and its Finalizer ran, which would trigger Pro to crash (unobserved exception re-thrown from finalizer thread where no one will handle it).  Compare to the first version where if the caller awaited the completion of the returned Task<bool> in a try/catch block it could catch and handle this exception and potentially keep the application from crashing.