Async/Await in VB.NET

Synchronous I/O operations — reading a file, calling a web API, querying a database — block the calling thread until they complete, which in a WinForms or WPF application freezes the UI because the same thread that handles button clicks and repaints the window is stuck waiting. Asynchronous programming lets a method start a long-running operation, release the thread back to do other work, and resume exactly where it left off once the operation completes, without the overhead of manually managing callbacks or spinning up dedicated threads for every I/O call.

Marking a method Async allows it to use the Await operator inside its body; the method's return type becomes Task for a Sub-like method with no return value, or Task(Of T) when it returns a value of type T. When execution hits an Await expression, control returns to the caller immediately if the awaited Task hasn't completed yet, and the rest of the method runs later — via a compiler-generated state machine — once that Task finishes, resuming on a captured context by default.

The Task-based Asynchronous Pattern standardizes async APIs around Task and Task(Of T): Task.Run offloads CPU-bound work onto a thread pool thread when there's no natural async I/O API to await, Task.WhenAll awaits multiple tasks concurrently and completes once all of them finish (useful for firing off several independent web requests at once instead of awaiting them one at a time), and Task.WhenAny completes as soon as the first of several tasks finishes, which is handy for implementing timeouts by racing a real operation against a Task.Delay.

Exceptions thrown inside an Async Function are captured and stored on the returned Task rather than thrown immediately; they surface at the point where the Task is awaited, so wrapping the Await expression in a normal Try/Catch block catches the exception just as it would for synchronous code. When you use Task.WhenAll to await several tasks and more than one of them fails, awaiting the combined task only re-throws the first exception directly, though all exceptions remain accessible via the AggregateException on each individual faulted Task if you inspect them separately.

By default, Await captures the current SynchronizationContext (such as the WinForms UI context) and resumes the continuation on it, which is necessary when the code after Await needs to touch UI controls. In library or non-UI code that never touches the UI, calling Await someTask.ConfigureAwait(False) tells the runtime it doesn't need to resume on that original context, allowing the continuation to run on whatever thread pool thread is available, which avoids unnecessary context-switching overhead and reduces the risk of contributing to deadlocks in code that might otherwise be called synchronously.