Why exceptions in async methods are “dangerous” in C# 调用async方法,不进行await的时候,会丢失异常 exception disappear in async method

exception disappear when forgot to await an async method

 

Why exceptions in async methods are “dangerous” in C#

Error handling is a topic that sometimes is neglected when enterprise systems are developed, in C# or any other language, by the fact that there are many tools available in the market that allows us to just easily install and configure, and all the exceptions start being logged automatically. But, what if the wrong exceptions are being recorded? What if our application is hiding important errors and masking the real cause of the issues? It may be an absurd assumption for many developers, but in real-world scenarios, this situation is more common than we sometimes imagine.

To demonstrate what I’m trying to say with this short article, take a look at the code below:

class Program
    {
        static async Task Main(string[] args)
        {
            try
            {
                MyAsyncMethod();
            }
            catch(Exception ex)
            {
                Console.WriteLine("Show my exception:");
                Console.Write(ex.Message);
            }

        } 
    
        private static async Task MyAsyncMethod()
        {
            throw new ArgumentException("Exception from MyAsyncMethod");
        }
   }
If we run this Console application, what do you think is going to happen? Considering the MyAsyncMethod is throwing intentionally an ArgumentException, the most logical result for many is that the execution of the code will jump to the catch block (line 9). But, once we run the code, that is what actually happens:

No exception was thrown because the MyAsyncMethod routine is not awaited and the exception is literally lost with the Task. In that case, if we are using Application Insights or another logging system, the exception will never be recorded and we will not be able to know that exception occurred. And I’m not even talking about what we should do for handling this error properly in the application. Therefore, the first mistake is not awaiting the task if we want to catch the error in the parent method. If we use the “await” keyword, the exception will be thrown:

This solves the problem for a single simple task, but what if we have multiple tasks running within a method? What’s the result? If we don’t await any of the tasks, the result will be similar to the previous example with a single task: the exception will be lost with the tasks. However, if we await all the tasks, considering multiple exceptions can be thrown, one for each task, the result for the parent method may not be what we are expecting.

 

还有其他的,关于多任务处理的

 

作者:Chuck Lu    GitHub    
posted @   ChuckLu  阅读(31)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 全程不用写代码,我用AI程序员写了一个飞机大战
· DeepSeek 开源周回顾「GitHub 热点速览」
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了
历史上的今天:
2021-04-27 GitHub Actions 教程:定时发送天气邮件 weather
2021-04-27 vmware Increasing the size of a virtual disk
2020-04-27 Problem: Traffic sent to http://localhost or http://127.0.0.1 is not captured
2020-04-27 Feature IIS return error 0x800F0922
2020-04-27 Windows 8.1 / Windows 10 breaks my ASP.NET / IIS : “Service unavailable”
2018-04-27 卡巴斯基升级之后win10的vpn无法连接
2016-04-27 ConcurrentDictionary中的 TryRemove
点击右上角即可分享
微信分享提示