版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/Mabanana/article/details/84890888
异常处理
我们在编写代码的时候少不了会出现异常，那么我们在编程的时候就需要站在异常一定可能发生的角度来编写C#或其他语言的自定义异常处理程序，应对程序可能发生的错误，建立一个良好的C#自定义异常处理策略。
- 在做C#自定义异常处理的时候，最好能在应用程序所有的入口处（事件处理函数，主函数，线程入口）使用try-catch。但是不要在程序构造函数入口处添加try-catch，因为此处产生异常，它自己并没有能力来处理，因为它还没有构造完毕，只能再向外层抛出异常。
- 我们不能盲目的使用异常，因为使用异常可能会在一定程度上影响到程序的性能
- 将全局异常处理函数的委托加入到Application.ThreadException中，实现全局异常处理，但它只能处理主线程中未捕获的异常。在多线程异常处理时，工作线程/辅线程中产生异常，可以把它转给主线程来完成异常处理。如果线程之间不通知，是无法直接捕捉异常的。若没有去处理工作线程/辅线程中产生的异常，该异常将会“消失”掉。
- 为什么要把异常处理都交给主线程去做呢？举个例子：在WinForm里我们使用多线程来处理界面元素，一旦有异常发生就将异常消息显示出来。那么，是直接在异常发生后就MessageBox，还是将消息交给MainUI来统一显示？试想一下，程序要是复杂点或是有多个界面采用多线程来显示界面元素，那么采用前者，我们就算知道了异常的详细信息，但可能还是很难找到究竟是哪里出了问题。而通过MainUI来显示，情况就要好很多了，尤其是还设计到其他东西的时候（如：多语言环境）。
日志规约
- 应用中不可以直接使用日志系统中的API，而应依赖使用日志框架中的API，使用门面模式的日志框架，有利于维护和各个类的日志处理方法统一
- 日志文件推荐至少保存15天，因为有些异常具备以“周”为频次发生的特点
- 应用中的扩展体制（如打点、临时监控、访问日志等）命名方式：
appName_logType_logName.log 其中logType是日志类型，logName是日志描述。这种命名的好处有：可以通过文件名就可以知道日志文件属于什么应用，什么剋行，什么目的等。 - 避免重复打日志，避免浪费磁盘空间。
- 谨慎记录日志，即使删除观察日志
实例
/// <summary>
/// 将异常打印到LOG文件
/// </summary>
/// <param name="ex">异常</param>
/// <param name="LogAddress">日志文件地址</param>
public static void WriteLog(Exception ex,string LogAddress="")
{
//如果日志文件为空，则默认在Debug目录下新建YYYY-mm-dd_Log.log文件
if(LogAddress=="")
{
LogAddress = Environment.CurrentDirectory + '\\' +
DateTime.Now.Year + '-' +
DateTime.Now.Month + '-' +
DateTime.Now.Day + "_Log.log";
}
//把异常信息输出到文件
StreamWriter sw = new StreamWriter(LogAddress, true);
sw.WritLine("当前时间： " + DateTime.Now.ToString());
sw.WriteLine("异常信息：" + ex.Message);
sw.WriteLine("异常对象：" + ex.Source);
sw.WriteLine("调用堆栈：\n" + ex.StackTrace.Trim());
sw.WriteLine("触发方法：" + ex.TargetSite);
sw.WriteLine();
sw.Close();
}
调用方法
try
{
throw new Exception("测试异常");
}
catch (Exception ex)
{
WriteLog(ex);
总结
现在只是了解到这个打日志挺重要的，剩下的还需要多去使用…