In the previous post<\/a> I described the benefits regarding async eliding: performance and allocation (of course by using benchmark as a proof – let us be clear, no benchmark no proof). In this post I will show you that async eliding is not as sweet, great, perfect and lovely and it might seem to be. Let’s get to the point!<\/p>\n\n\n\n Firstly, I must truly apologise you. The heading is kind of a bait… not 100% though but still. Async eliding can cause the HTTP crash but it is not limited to it – I will just use it as an example. Let’s consider the following example:<\/p>\n\n\n\n The first method, i.e. Does the second method, i.e. Well yes, but actually no. The This time the heading is 100% not a bait. To give some concrete examples let’s consider the following example:<\/p>\n\n\n\n If you’ve just thought about DivideByZeroException, then you are absolutely right, it will be thrown in a moment, but the point is in what circumstances? To understand the difference please open in a separate tab tests<\/a> that I’ve prepared for this (I could have pasted it here but it would have produced to much noise). <\/p>\n\n\n\n Let’s focus on the Why would we want to assign Task to the variable and then await it? <\/p>\n\n\n\n We can think of a scenario where we want to run 3 tasks and waits for any of them to complete, in other words we want to use Task.WhenAny<\/a>. Let’s add two methods to the There are two tests that show the behaviour of such a scenario: As always I’ve prepared an example and you can find it on my github<\/a>, project: async-eliding-part-2, test project: async-eliding-part-2-tests. I encourage you to go through the code, debug it and try to test your own scenarios. Unfortunately, I haven’t prepare any benchmark this time, but I attach great article <\/a>to read about the async eliding.<\/p>\n\n\n\n Async eliding is an interesting approach. On the one hand it can improve the performance and the allocation, but on the other hand the program behaviour changes which can cause to the unexpected application errors. Recommended way of using async eliding is not to use it, unless you have a really good reason to boost some of the hot paths` performance of your application and, above all, you are aware of the potential consequences.<\/p>\n\n\n\n Have a nice day, bye!<\/p>\n","protected":false},"excerpt":{"rendered":" Introduction In the previous post I described the benefits regarding async eliding: performance and allocation (of course by using benchmark as a proof – let…<\/p>\nHTTP crash<\/h1>\n\n\n\n
public class HttpClientExecutor\n{\n private readonly string _uri= \"https:\/\/postman-echo.com\/get?foo1=bar1&foo2=bar2\";\n\n public async Task<string> GetWithUsingAndWithoutEliding()\n {\n using var _httpClient = new HttpClient();\n return await _httpClient.GetStringAsync(_uri);\n }\n\n public Task<string> GetWithUsingAndWithEliding()\n {\n using var _httpClient = new HttpClient();\n return _httpClient.GetStringAsync(_uri);\n }\n}<\/code><\/pre>\n\n\n\nGetWithUsingAndWithoutEliding<\/code>, creates the httpClient<\/code> and gets the response from the provided uri. The httpClient<\/code> is then disposed. By the way, this is not the best approach of the HttpClient<\/code> usage because of the socket exhaustion (probably the best approach now is to use the IHttpClientFactory<\/a>), but it shows one of the async eliding problems.<\/p>\n\n\n\nGetWithUsingAndWithEliding<\/code>, do the same?<\/p>\n\n\n\nHttpClient<\/code> is instantiated within the using statement and the GetStringAsync<\/code> method is invoked, but then the TaskCanceledException <\/code>would be thrown. It happens because the httpClient<\/code> is disposed during the HTTP GET request processing.<\/p>\n\n\n\nExceptions<\/h1>\n\n\n\n
public class ExceptionExecutor\n{\n public async Task<int> DivideWithoutEliding(int dividend, int divider)\n {\n var result = dividend \/ divider;\n return await Task.Run(() => result);\n }\n\n public Task<int> DivideWithEliding(int dividend, int divider)\n {\n var result = dividend \/ divider;\n return Task.Run(() => result);\n }\n}<\/code><\/pre>\n\n\n\nDivideWithoutEliding_DividerIsZeroAndAndAssignTaskToTheVariableFirst_WhenAwaitThrowsDivideByZeroException<\/code> and DivideWithEliding_DividerIsZeroAndAssignTaskToTheVariableFirst_WhenAssignToTheVariableThrowsDivideByZeroException<\/code>tests. The first one throws the exception NOT when we assign to the task<\/code> variable but when we await it. The second one throws the exception when we assign to the task<\/code> variable. It happens because when we do the classic async\/await approach (not elided) the exception is packed in the returned Task. On the other hand, when we do the async eliding, the exception is thrown before we use the await keyword.<\/p>\n\n\n\nExceptionExecutor<\/code> class:<\/p>\n\n\n\npublic async Task<Task<int>> DivideMany_WithoutEliding(int dividend, int divider)\n{\n var task1 = DivideWithoutEliding(dividend, divider);\n var task2 = DivideWithoutEliding(dividend, divider);\n var task3 = DivideWithoutEliding(dividend, divider);\n\n return await Task.WhenAny(result1, result2, result3);\n}\n\npublic async Task<Task<int>> DivideMany_WithOneEliding(int dividend, int divider)\n{\n var task1 = DivideWithoutEliding(dividend, divider);\n var task2 = DivideWithoutEliding(dividend, divider);\n var task3 = DivideWithEliding(dividend, divider);\n\n return await Task.WhenAny(task1, task2, task3);\n}<\/code><\/pre>\n\n\n\nDivideMany_WithoutEliding_DividerIsZero_WhenAwaitSecondThrowsDivideByZeroException<\/code> and DivideMany_WithOneEliding_DividerIsZero_WhenFirstAwaitThrowsDivideByZeroException<\/code>. <\/p>\n\n\n\nSummary<\/h1>\n\n\n\n