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 Geoprocessing.MakeValueArray(g, null, @"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.         var valueArray = Geoprocessing.MakeValueArray(g, null, @"8000 Meters");  
9.         Geoprocessing.ExecuteToolAsync("analysis.Buffer", valueArray);  
10.         return true;  
11.     });              
12.     return something;  
13. }  

[JohnJones · Accepted solution]

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.

[GyanendraGurung]

Awesome !

Thanks ! Thank you for your detailed answer. That clears a lot of stuff for me. I had been reading all about these stuff, but I was not able to grasp the whole picture clearly. Your answer has probably taught me to be more careful while coding and has shown me how to improve them. Thanks to you, I know much more about why we should async and await. Thanks a lot !!