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


    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.

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

  • 相关阅读:
    ros 录制
    shell 截取字符串
    Linux 关机
    shell获取字符串长度
    ubuntu14.04 设置开机自启动脚本
    获取本机ip的shell脚本
    shell 杀掉指定进程的服务
    html 绘制矩形轨迹,选中区域
    shell模拟ctrl c停止
    shell 字符串提取数字
  • 原文地址:https://www.cnblogs.com/chucklu/p/16197685.html
Copyright © 2020-2023  润新知