Beware of “async void” in C#

Post by zamalek » Wed, Jul 08, 2015, 6:14 PM UTC

mhomde wrote: post #8

zamalek wrote: post #6

To be a bit facetious: remember that an unhandled exception in your main program thread will also crash your program. The article holds a very valuable lesson, though: just because you don't see "Task" doesn't mean that there aren't threads involved. In this way `async void` is deceptive but is certainly not something that is broken or something that you should never use. There is actually a case where an exception i…

On a related note, I really dislike the dispatcher paradigm, especially with the inclusion of async-await. For good performance of IO async calls you usually want to call .ConfigureWait(false), otherwise it will wait for the UI context to switch back to, you might even risk thread starvation. But now each async call is a potential switch out of the UI thread and certain crasch down the road, meaning you have to put D…

Post by asveikau » Wed, Jul 08, 2015, 6:24 PM UTC

zamalek wrote: post #11

mhomde wrote: post #8

Earlier quoted context omitted.

On a related note, I really dislike the dispatcher paradigm, especially with the inclusion of async-await. For good performance of IO async calls you usually want to call .ConfigureWait(false), otherwise it will wait for the UI context to switch back to, you might even risk thread starvation. But now each async call is a potential switch out of the UI thread and certain crasch down the road, meaning you have to put D…

> the dispatcher paradigm is one of the thing I dislike the most about coding UI stuff in .Net It inherits it from Windows. As far as I know, most GUIs have a dispatcher because . I definitely think that there could have been a better way to solve the problem (method interception), however, I think that TPL does add value. In your case you cited intense IO as one reason to call `.ConfigureAwait(false).` The thing is:…

Post by DougBTX » Wed, Jul 08, 2015, 8:28 PM UTC

mhomde wrote: post #2

To make it perfectly clear , "async void" should be replaced with "async Task" The async stuff is interesting in that akin to generics it has an almost cancerous effect on your code. When you start using them they tends to spread to large parts of your code base if you're not careful. It's awesome that C# now has such good support for parallelism and asynchronicity... but I remain in the opinion that a lot of this st…

Post by solarexplorer » Wed, Jul 08, 2015, 8:54 PM UTC

mhomde wrote: post #10

saosebastiao wrote: post #7

Earlier quoted context omitted.

I've been pleasantly surprised by the async workflows in F#. Behind the scenes it is one big ass monadic construct that has been grafted onto the language, but it doesn't feel that way at all when you use it...it is incredibly elegant and easy to read/write and understand exactly what is happening in terms of control flow. I think it is perfectly possible for C# to improve it without starting over from scratch, simpl…

Yeah, but the problem with C# is not that it isn't working, and it is pretty legible and easy to understand. The problem is the syntax and lack of some abstractions. F# syntax is probably more suited for a certain style of programming. You could try to rework C# without concern for breaking current behavior and making it more cohesive and consistent... but at that point it won't be C# I think. What I'd really like th…

Post by jongalloway2 » Wed, Jul 08, 2015, 9:49 PM UTC

   private static async void OnTimerFired(object sender, ElapsedEventArgs args)

   {
	Exception exception = null;
	try
	{
		await Task.Delay(1000);

		// this is NOT going to terminate your process!
		throw new Exception();
	}
	catch (Exception ex)
	{
	  exception = ex;
	}

	if (exception != null)
	{
	  ...
	}
  }