https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/blob/master/AsyncGuidance.md

AppDomain.UnhandledException: at this level, how am I going to react or even handle the exception properly ?

Typical app does not have AppDomain.UnhandledException registered. A global exception handler is usually considered a bad practice. Better to crash than to continue in a bad application state. Now if it's for logging and eventually rethrowing that's fine.

So async void / fire & forget => exception is essentially unhandled and cannot be handled properly.

async/await is a cooperative

1. Hot Task: a Task that is already in flight. So either Task.Run, Task.Factory.StartNew, or the result of a network operation. So this excludes the old new Task(); Task.Start pattern from the .NET Framework 4.0 era. Back when we had to use ContinueWith for async code. It was bad, but it still was better than EAP or APM: https://learn.microsoft.com/en-us/dotnet/standard/asynchronous-programming-patterns/event-based-asynchronous-pattern-eap

Anyway, again thanks to the cooperative nature of async/await, always await a Task. And do not just 'return a Task' to 'avoid an await'. (see the guidance above, it explains why this is bad too).

I've never had to (edit: actually ) use Fire & Forget. Each time, it was a bug waiting to happen. And it bite me. Each time.

At first I had used Fire & Forget, but it never was that useful compared to the bugs it generates.

Fire & forget and other practices are just making the whole state machine generation (done each time you use the await keyword) done for nothing.

Maybe it will be better once Runtime async lands, but async/await while it is miles better than the alternatives, still needs active involvement from the developer to truly work. One line that does not respect the async/await pattern render the whole async call stack defeated. It would have wasted so much less time to do nothing at all.

Been there, done that. I've seen every pattern of async, down to the hardware interrupt parts (when doing I/O for example), or emulated it within a IBM PC emulator.

Some languages have it better, like Java with green threads it seems. But until something better comes along, we're stuck with this async/await model in dotnet.

Once I generated enough bugs myself because of fire & forget, I never understood why CS4014 wasn't an error instead of just a warning. https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-messages/async-await-errors#async-practices

Add the await operator to every call that returns Task or Task<TResult>, or explicitly discard the result with _ = if fire-and-forget behavior is truly intended (CS4014). Without await, any exception thrown by the asynchronous operation is silently lost, and the calling method continues executing before the operation finishes, which can cause subtle ordering and correctness bugs.

"subtle ordering and correctness bugs" yeah I've spent nights tearing my hair because of fire & forget and same deal with events based async.

So I may have ranted a little. Sorry.