Stop using async void in C#! Do this instead.

Hello everybody I'm Nick and in this video I will show you why you should not be using async void in C#. It is a very common mistake that can have very catastrophic effects for your application and in this video I will explain why.

Don't forget to comment, like and subscribe :)

Social Media:

#csharp #dotnet

[DeadDad]

Would definitely like to see how to properly code for long running tasks, please! You are awesome and I sincerely appreciate your videos! Thank you for your time. Edit: No, I didn't know all the caveats, thank you for explaining the issue and describing why and how it all works.

[TheSilent]

I learned about Task and exceptions the hard way. This video explains it really well! I'd love to get some info on long running tasks, as that is something I deal with at work every day.
Thanks, Nick!

[WagnerGFX]

I'm always up for more videos on async stuff, since it's one of the most unintuitive areas in C#.
On an unrelated note, I would also love to see some videos about unsafe coding. When it's needed or not, the pitfalls to lookout for and common practices to follow.

[BluSouls]

Having more info about long running tasks would be great. I often heard that you shouldn't create long running background tasks but never found a clear explanation why.

[ivandrofly]

6:00 - good point about Func<Task> and Action<T>

[Kevmoens]

Internally we create an extension method to tasks that requires an Action<Exception> and optional Action<T> for continuing with. Saw this from Brian Lagunas video on YouTube years back.

[mihankolt]

Yeah, video about long running Tasks would be helpful!

[PockyBum]

Thank you for collecting this info in one place. This is exactly what I was curious about. Great info. I'd love that long running tasks video!

[chrismantonuk]

Yes please Nick, would really like to learn more about long running background tasks. Especially with regards to desktop\WPF\WinForms

[orterves]

The Action<> silent void is definitely a gotcha to keep a lookout for

[GlassScissors]

Hi Nick, Thank you for the great video and explanations.
I would be very interested in a long background runner tasks video :)

[pablocom]

I really love videos on C# asynchronous programming model, it's so elegant the Task-Based approach🤘😍

[islandparadise]

Good video! And yes, long running background tasks please 🙏

[lexer_]

I almost didn't click on this one because I expected yet another (pedantic) rant on how async void hides the function from the exception stack trace and whatnot as seemingly everyone that talks about c# has done before. But this is actually highlighting a small but helpful and important detail that I didn't know about.

[ksdvishnukumar]

Hi Nick,

Very nice video. Am more interested on long running backgroundTask video

[LozrusX]

Very interesting, especially since we are forced by the class library to use async void in some places, it's great to know the gotchas. I hadn't realised how dangerous unhandled exceptions could be inside an async void function.
For fire & forget I'd typically just receive the Task but not await it ( _ = DoThing() ), or use a message queue and handle it elsewhere, depending on what the task actually is.
Yes, a video about long running threads would be great. I frequently use a thread to monitor external hardware and am still using the old Thread.Start() API, with a worker loop that does the hardware monitoring logic and a frequent Thread.Sleep(). This usually runs for the life of the application, and it works well, managing a job queue for the hardware, re-establishing connections, raising event etc. and is a very mature pattern for us. but I'm sure that in the new async world there's a more modern design pattern that I should be considering.

[TampaCEO]

As for extremely long running tasks however, I definitely recommend utilizing the PUB/SUB message queue methodologies. The subscriber model is truly a "fire and forget" and will completely release your threads.

Thanks for another great video.

[ali_randomNumberHere]

nick:
your code could be in danger.
my code:
I'm not in danger, I am the danger skyler.

[peterrauscher]

Great video! Saved me a headache, I'm coming from async/await in JS and then async/await in Python, now using this paradigm in C# and of course there's all these subtle differences in every language 🙄

[alexanderkvenvolden]

I would definitely like to see the long-running task version!

The thing I do for fire and forget is just have a small helper method (called FireNForget) that takes a Func<Task<>> (func so it can capture both sync and async exceptions), and wraps everything in a try-catch(Exception ex), with the catch block (carefully!) logging the exception where it can be noted. FireNForget is very deliberately made short and simple enough that as little as possible is done outside the try-catch guard, and hasn't failed me. Does this seem like a good solution? Does it seem like there are any problems with this?