.NET Core学习笔记(7)——Exception最佳实践

1.为什么不要给每个方法都写try catch

为每个方法都编写try catch是错误的做法，理由如下：

a.重复嵌套的try catch是无用的，多余的。

这一点非常容易理解，下面的示例代码中，OutsideMethodA中的try catch是不起作用的。

            class NestedTryCatch
            {
                internal void OutsideMethodA()
                {
                    try
                    {
                        this.InsideMethodB();
                    }
                    catch (Exception ex)
                    {
                        Console.WriteLine(ex.ToString());
                    }
                }

                private void InsideMethodB()
                {
                    try
                    {
                        this.ExceptionMethod();
                    }
                    catch (Exception ex)
                    {
                        Console.WriteLine(ex.ToString());
                    }
                }

                private void ExceptionMethod()
                {
                    throw new NotImplementedException("You did't implement this method!");
                }
            }

b.多余的try catch会掩盖严重的bug，将bug珍藏在log里并不会增值。

下面的代码中，一旦参数uri为null，意味着程序逻辑必然有bug，存在错误的调用。与其将这个bug和HttpRequestException混在一起写log，然后相忘于江湖。不如大大方方在开发阶段就每次crash，强迫必须修复隐藏的逻辑错误。

同时我们可以看到，catch里再次返回了null，这又是一种不负责任给上层代码挖坑的行为。上层代码两眼一黑，就得一个null，啥也不知道，估计也不敢问。
注释的部分给出了两种解决方案，Assert或者主动throw。

        internal async Task<string> DownloadContent(string uri)
                {
                    //Debug.Assert(!string.IsNullOrEmpty(uri));

                    //if (string.IsNullOrEmpty(uri))
                    //{
                    //    throw new ArgumentNullException("uri is null");
                    //}

                    try
                    {
                        using (var httpClient = new HttpClient())
                        {
                            return await httpClient.GetStringAsync(uri);
                        }
                    }
                    catch (Exception ex)
                    {
                        Console.WriteLine(ex.ToString());
                        return null;
                    }
        }

c.当程序因Exception进入不可继续的状态时，通过try catch避免程序crash，除了可以稍微体面地退出，并没有更大意义。

例如网络游戏在运行过程中，发生了错误。本地数据与服务器不再同步，是不会允许继续运行，也不会承认期间产生的本地数据。
硬用代码举例的话，就比如在构造函数里搞个try catch吞掉Exception，这个new出来的实例谁还敢用的，请站出来……

d.都知道空的try catch是错误的。

try
{
    ……
}
catch{ }

难道加个日志就会产生质变了嘛？

try
{
    ……
}
catch (Exception ex)
{
    Log.Error(“xxxx方法失败了！”);
}

2.何时使用try catch？只提出问题不给出解决方案，会被骂耍流氓。下面我们来分析几个适于添加try catch的场景。

a.仅在你真的打算，并且知道如何处理当前的Exception时，加try catch。比较明显的场景是网络请求中的retry。

        public async Task<string> HandleHttpRequestExceptionAsync()
        {
            HttpClient client = new HttpClient();
            try
            {
                return await client.GetStringAsync("http://www.ajshdgasjhdgajdhgasjhdgasjdhgasjdhgas.tk/");

            }
            catch (HttpRequestException ex)
            {
                //Simulate to try again.
                //log here then retry
                return await client.GetStringAsync("http://www.dell.com/");
            }
            finally
            {
                client?.Dispose();
            }
        }

b.当常规流程控制无法避免异常时，加try catch。

通常可以用if来避免的问题，就不应通过try catch处理。反例如IO处理，无法确认用户会不会拔U盘，该情况下需catch IOException。

c.功能性的类库中的API缺乏业务逻辑，不知道如何处理Exception时，不应加try catch。应将错误抛给上层，由存在业务逻辑的调用方处理。

比较典型的，在使用Microsoft UI Automation的API时，找元素的API可能会抛出COMException。API本身认为调用方传参错误，传入了不存在元素的ID。但上层的调用代码会知道，是因为当前页面未加载完全。如果我们希望在这里retry或者忽略这个错误，try catch是合理的。

d.为了体面的退出。

在顶层加入try catch记录log是可行的。调用堆栈的信息会完整的保存下来。（针对Task的异常堆栈丢失问题，请看《.NET Core学习笔记（3）——async/await中的Exception处理》）

3.在顶层代码应用try catch的一些可行做法

a.如果我们真的害怕且不能接受crash，那么可以试着在Main方法里加个try catch，然后记录log。
b.不是主线程的UnHandle Exception可以通过AppDomain.UnhandledException来处理。

        public static void Main()
        {
            AppDomain currentDomain = AppDomain.CurrentDomain;
            currentDomain.UnhandledException += new UnhandledExceptionEventHandler(MyHandler);

            try
            {
                throw new Exception("");
            }
            catch (Exception e)
            {
                Console.WriteLine("Catch clause caught : {0} \n", e.Message);
            }

            throw new Exception("");
        }

        static void MyHandler(object sender, UnhandledExceptionEventArgs args)
        {
            Exception e = (Exception)args.ExceptionObject;
            Console.WriteLine("MyHandler caught : " + e.Message);
            Console.WriteLine("Runtime terminating: {0}", args.IsTerminating);
        }

默认情况下.NET 程序将会退出，因为此时的程序因为这个unhandle exception，被认为进入了未知，且不可继续的状态。
此时即使通过某些特殊手段保持程序不退出，也没有任何意义。unhandle exception的意思就是有crash bug没处理。开发阶段干嘛去了。
https://docs.microsoft.com/en-us/dotnet/standard/threading/exceptions-in-managed-threads#application-compatibility-flag
上述链接提供了程序不退出的可能选项，但我认为实不可取。

4.判断Exception类型的一些技巧，

仍然以HttpClient.GetStringAsync举例，我们可以通过查看MSDN得知该方法可能抛出如下几个Exceptions：

a.AugumentNullException

我们上文提过了，在上层调用代码可以通过null check来避免，或者主动抛出exception。
b.HttpRequestException

网络错误都会抛这个异常，通常我们需要捕获该异常，并通过异常中返回的Status或是其他信息来针对性处理。
c.TaskCanceledException

在以下两种情况会被抛出：

• • 指定了HttpClient.Timeout同时本次网络请求超出指定时间
  • 在使用Task异步编程时，在Task Completed之前调用CancellationTokenSource对象的Cancel()方法

那么在写代码的时候，就要判断是否是.NET Core，同时符合以上两点。否则就无需对该异常添加处理。
举着例子更重要的目的是想说，除了顶层代码的最后一道用于记录log的try exception。没有任何理由用到基类Exception。

文中提到的示例代码可以在这里找到：
https://github.com/manupstairs/PracticeOfException
本篇提到了处理Exception时的一些实践经验，且为一家之言，如有错误的地方还请指出。