客户端日志和异常处理

一. 使用Serilog结构化日志记录日志信息

Serilog包的引用和使用语法都可以在网上找到(https://github.com/serilog/serilog/wiki/),不再赘述,这里仅分享一下自己在项目中的简单使用。
FileLogHelper帮助类对日志记录进行封装:

public static class FileLogHelper
{
    /// <summary>
    /// 日志模板
    /// </summary>
    private static string ErrorTemplate = "{Timestamp:yyyy-MM-dd HH:mm:ss} {Message:j} {NewLine} {Exception} {NewLine}";
    private static string InfoTemplate = "{Message:j} {NewLine}";

    /// <summary>
    /// 记录异常信息
    /// </summary>
    private static ILogger ErrorLog;

    /// <summary>
    /// 记录各类日志信息
    /// </summary>
    private static ILogger InfoLog;

    static FileLogHelper()
    {
        InitLog();
    }

    private static void InitLog()
    {
        ErrorLog = new LoggerConfiguration()
        .MinimumLevel.Warning() // 最小日志级别,小于该级别的日志不会记录
        .WriteTo.Map(
        le => "",
        (d, lc) =>
        {
            lc.File($"Log/Error/{d:yyyyMMdd}.txt", // 日志文件路径,文件以日期命名
            rollingInterval: RollingInterval.Day, // 日志文件按天滚动创建,即每天创建新的文件
            outputTemplate: ErrorTemplate, // 指定日志输出模板
            rollOnFileSizeLimit: true, // 滚动文件是否限制大小 
            fileSizeLimitBytes: 52428800 // 滚动文件限制的大小,单位byte, 52428800为50M
            );
        }).CreateLogger();

        InfoLog = new LoggerConfiguration()
        .MinimumLevel.Information()
        .WriteTo.Map(
        le => "",
        (d, lc) =>
        {
            lc.File($"Log/Info/{d:yyyyMMdd}.txt",
            rollingInterval: RollingInterval.Day,
            outputTemplate: InfoTemplate,
            rollOnFileSizeLimit: true,
            fileSizeLimitBytes: 52428800
            );
        }).CreateLogger();
    }

    /// <summary>
    /// 记录异常信息
    /// </summary>
    /// <param name="exception"></param>
    /// <param name="message"></param>
    public static void LogError(Exception exception, string message = "错误")
    {
        ErrorLog.Error(exception, message);
    }

    /// <summary>
    /// 记录各类日志信息(结构化记录)
    /// </summary>
    /// <param name="title"></param>
    /// <param name="message"></param>
    /// <param name="detailMessage"></param>
    /// <param name="paramter"></param>
    public static void LogInfo(string title, string message, string detailMessage, object paramter)
    {
        LogInfoView log = new LogInfoView(title, message, detailMessage, paramter);
        InfoLog.Information("{@log}", log);
    }

    /// <summary>
    /// 结构化日志对象
    /// </summary>
    private class LogInfoView
    {
        public LogInfoView(string title, string message, string detailMessage, object paramter)
        { 
            this.Title = title;
            this.Message = message;
            this.DetailMessage = detailMessage;
            this.Paramter = paramter;
        }

        public string DateTime { get; set; } = System.DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss");

        public string Title { get; set; }

        public string Message { get; set; }

        public string DetailMessage { get; set; }

        public object Paramter { get; set; }
    }
}

帮助类中创建了两个静态日志对象ErrorLog和InfoLog,方法LogError通过ErrorLog对象记录异常信息,方法LogInfo通过InfoLog对象记录一般日志信息:

  • ErrorLog和InfoLog分别指定了不同的日志文件目录(Log/Error/与Log/Info/),便于区分和查找;
  • InfoLog使用结构化日志,将日志信息包装成LogInfoView对象,在文本中以JSON格式记录。InfoLog使用了与ErrorLog不同的日志模板,仅保留了{Message:j},这样一条记录就是一个JSON数据,整个日志文件中的数据就是JSON Lines格式,方便内容解析。

按上述设置后,产生的日志文件目录如下:
在这里插入图片描述

结构化日志InfoLog产生的日志内容如下,每一行都是json格式:
(用户密码是不应该输出到日志的,这里只是为了演示效果):
在这里插入图片描述

非结构化的ErrorLog产生的日志内容如下:
在这里插入图片描述

二. 捕获全局异常

winform客户端中,如果程序发生异常后没有对其捕获处理,就会造成系统崩溃,影响用户体验。一种保险的方式是添加全局异常捕获事件,所有未处理的异常都会在这里被捕获到,从而避免系统直接闪崩。异常信息的记录使用了上面第一节中的FileLogHelper帮助类。

internal static class Program
{
    /// <summary>
    /// 应用程序的主入口点。
    /// </summary>
    [STAThread]
    static void Main()
    {
        Application.EnableVisualStyles();
        Application.SetCompatibleTextRenderingDefault(false);
        CatchApplicationException(); // 捕获全局异常
        Application.Run(new MainForm());
    }

    /// <summary>
    /// 捕获全局异常
    /// </summary>
    private static void CatchApplicationException()
    {
        //捕获UI异常
        Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);
        Application.ThreadException += OnUIThreadExceptionCatched;
        //捕获非UI异常
        AppDomain.CurrentDomain.UnhandledException += OnDomainExceptionCatched;
    }

    /// <summary>
    /// 捕获UI异常
    /// </summary>
    /// <param name="sender"></param>
    /// <param name="e"></param>
    private static void OnUIThreadExceptionCatched(object sender, ThreadExceptionEventArgs e)
    {
        FileLogHelper.LogError(e.Exception, "未处理的UI异常");
        MessageBox.Show("软件发生UI错误!", "提示", MessageBoxButtons.OK, MessageBoxIcon.Error, MessageBoxDefaultButton.Button1, MessageBoxOptions.DefaultDesktopOnly);
    }

    /// <summary>
    /// 捕获非UI异常
    /// </summary>
    /// <param name="sender"></param>
    /// <param name="e"></param>
    private static void OnDomainExceptionCatched(object sender, UnhandledExceptionEventArgs e)
    {
        FileLogHelper.LogError((Exception)e.ExceptionObject, "未处理的异常");
        MessageBox.Show("软件发生错误!", "提示", MessageBoxButtons.OK, MessageBoxIcon.Error, MessageBoxDefaultButton.Button1, MessageBoxOptions.DefaultDesktopOnly);
    }
}

三. 使用AOP统一处理异常

使用AOP处理异常的好处就是不用写大量的try-catch,一是减少重复的代码,二是不让try-catch影响核心代码的可读性;缺点就是统一处理异常后,灵活性会降低。要不要使用可以根据自己的具体情况来。

在异常处理方面,使用起来比较方面的AOP组件,这里推荐两个:一个是Postsharp(https://doc.postsharp.net/),另一个是Rougamo(肉夹馍,https://github.com/inversionhourglass/Rougamo)。推荐的原因是,这两个都可以通过特性Attribute标注的方式进行代码织入,都支持应用于方法、类、程序集等不同的粒度,且都支持设置可访问性属性。一些区别在于:Rougamo是完全开源的,可以随意使用;而Postsharp分商业版和社区版,引用ChatGPT上的解释,比较明了:

在这里插入图片描述

社区版虽说功能有限制,但也足够我们使用了。

这里便以PostSharp举例。如何引用Postsharp可以参考官方文档:https://doc.postsharp.net/deploymentconfiguration/deployment,在NuGet中直接搜索安装就可以。

我们创建一个自己的异常处理Attribute,如下:
(参考文档:https://doc.postsharp.net/custompatterns/aspects/tutorials/exception-handling)

/// <summary>
/// 异常处理
/// </summary>
[PSerializable]
public class LogAttribute : OnExceptionAspect
{
    /// <summary>
    /// 异常处理结束后的方法返回值
    /// </summary>
    public object ReturnValue { get; set; }

    /// <summary>
    /// 异常处理方式
    /// FlowBehavior.Return:忽略异常。如果方法有返回值,必须通过设置ReturnValue来设置方法的返回值。
    /// FlowBehavior.Continue:忽略异常,在OnException方法中,与FlowBehavior.Return的作用一样。
    ///                       同样的,如果方法有返回值,必须通过设置ReturnValue来设置方法的返回值。
    /// FlowBehavior.RethrowException:在异常处理程序退出后重新引发原始异常。
    /// FlowBehavior.ThrowException:一旦异常处理程序退出,就会抛出一个新的异常。
    ///                             当应该向用户隐藏原始异常的详细信息时,或者当要显示更有意义的异常时,这很有用。
    ///                             抛出新异常时,必须将新异常对象分配给MethodExecutionArgs的exception成员。
    /// </summary>
    public FlowBehavior FlowBehavior { get; set; } = FlowBehavior.Return;

    /// <summary>
    /// 不记录日志
    /// </summary>
    public bool IgnoreLogRecord { get; set; } = false;

    /// <summary>
    /// 捕获异常
    /// </summary>
    /// <param name="args"></param>
    public override void OnException(MethodExecutionArgs args)
    {
        if (!IgnoreLogRecord)
        {
            // 记录异常日志
            FileLogHelper.LogError(args.Exception);
        }
        
        args.FlowBehavior = FlowBehavior; // 设置异常处理方式
        args.ReturnValue = ReturnValue; // 设置方法返回值
    }
}

自定义的LogAttribute 类中,新加了三个属性:ReturnValue、FlowBehavior、IgnoreLogRecord

  • ReturnValue属性:对于有返回值的方法发生异常时,通过ReturnValue属性,我们可以自定义异常处理结束后的方法返回值;
  • FlowBehavior属性:可以用来设置异常处理方式,上面的代码中我们默认设置为FlowBehavior.Return,即在异常处理程序OnException处理完后忽略异常。
  • IgnoreLogRecord属性:可以用来设置是否记录异常信息,配合上面第一节说的日志记录来使用,默认记录日志。

接下来我们举几个例子来演示如何使用它。

  1. 在有返回值的方法中,如果想忽略异常并指定异常发生后的返回值,可以这样使用:
private void OnLoginFormLoad(object sender, EventArgs e)
{
    m_allRoles = GetLoginRoles();
}

/// <summary>
/// 获取角色集合
/// 发生异常后返回null
/// </summary>
/// <returns></returns>
[Log(ReturnValue = null)]
private List<LoginRole> GetLoginRoles()
{
    using (UDPDbContext dbContext = new UDPDbContext())
    {
        dbContext.Dispose(); // 这里故意释放掉数据库上下文,为的是让下面的代码抛出异常
        return dbContext.LoginRoles.ToList();
    }
}

窗体Load方法中调用GetLoginRoles()方法获取角色集合,GetLoginRoles()方法上我们用LogAttribute进行标记(特性标记可以省去特性类名后面的“Attribute”),并指定ReturnValue = null,即方法发生异常后,返回null。

我们打断点进行观察,异常发生后,进入异常处理程序OnException,在异常处理程序中记录日志(默认记录),设置异常处理方式(默认FlowBehavior.Return忽略异常),最后设置返回值ReturnValue,这个ReturnValue的值就是我们在方法上标记LogAttribute时指定的。
在这里插入图片描述
异常处理程序执行完后,程序继续执行,在OnLoginFormLoad方法中,发现GetLoginRoles()并没有抛出异常,并且返回了null,达到了预期效果。
在这里插入图片描述

  1. 如果担心基础层的日志帮助类FileLogHelper出现异常,这种情况下,一般要吞噬掉异常,不能让日志记录的异常影响到我们的业务逻辑,并且我们不应该再去让异常处理程序OnException去记录日志了,因为此时记录日志的代码已经不能正常工作了。

使用LogAttribute特性,我们可以这样处理:

[Log(AttributeTargetMemberAttributes = MulticastAttributes.Public, IgnoreLogRecord = true)]
public static class FileLogHelper
{
    /*
     * 此处省略日志记录代码,与第一节中的代码保持一模一样
     */
}

LogAttribute特性直接应用于FileLogHelper类上,并通过给AttributeTargetMemberAttributes 属性赋值MulticastAttributes.Public,使其仅对类中的public方法起作用;IgnoreLogRecord 赋值为true,则在异常处理程序OnException中不记录异常。

  1. 还可能遇到一种情况:对整个类的异常统一设置异常处理方式后,对其中的个别方法需要特殊处理。比如类中的大部分方法都不需要记录日志,但是对于其中的某个方法需要记录异常日志。
    举个代码示例,下面的MainForm窗体类中,除了登录方法OnLoginOutButtonClick外,其他的都不需要记录异常日志,那我们可以这样进行特性标注:
[Log(AspectPriority = 1, IgnoreLogRecord = true)]
public partial class MainForm : Form
{
    public MainForm()
    {
        InitializeComponent();
    }

    private void InitializeComponent()
    {
        // ...
    }

    private void OnMainFormLoad(object sender, EventArgs e)
    {
        // ...
    }

    [Log(AspectPriority = 2, IgnoreLogRecord = false)]
    private void OnLoginOutButtonClick(object sender, EventArgs e)
    {
        // ...
    }
}

由于使用了多层异常处理特性,我们需要使用AspectPriority属性来指定优先级。当符合多个异常处理配置的条件时,按优先级高的来处理(AspectPriority值大的)。参考文档:https://doc.postsharp.net/custompatterns/aspects/applying/attribute-multicasting

  1. 异常处理还可以应用于整个程序集,如下,在程序集文件AssemblyInfo.cs中进行配置,AssemblyInfo.cs文件在项目的Properties路径下:
    在这里插入图片描述

以上就是常见的使用场景。

这里再做一点扩展了解:
Postsharp和Rougamo都是通过静态织入的方式实现了AOP,即在编译时将额外的异常处理代码织入到我们的源代码中。
我们拿上面的日志帮助类FileLogHelper为例,使用[Log(AttributeTargetMemberAttributes = MulticastAttributes.Public, IgnoreLogRecord = true)]进行标记后,进行编译,然后将编译后的dll使用反编译工具查看源码:

在这里插入图片描述
可以看出,FileLogHelper类中的Public方法在编译后自动加上了try-catch块。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
WebSocket客户端异常断开是指在WebSocket通信过程中,客户端与服务器之间的连接意外中断或出现异常情况导致通信无法继续进行的情况。以下是一些可能导致WebSocket客户端异常断开的原因: 1. 网络问题:网络中断、网络延迟过高、网络不稳定等因素可能导致WebSocket客户端与服务器之间的连接中断。 2. 服务器问题:服务器故障、服务器重启、服务器负载过高等原因可能导致WebSocket客户端无法正常连接或通信中断。 3. 客户端问题:客户端程序错误、客户端设备故障、客户端程序崩溃等原因可能导致WebSocket客户端异常断开。 4. 安全策略限制:某些安全策略可能会限制WebSocket连接,例如跨域访问限制、防火墙设置等,这可能导致WebSocket客户端无法连接或通信中断。 为了解决WebSocket客户端异常断开的问题,可以采取以下措施: 1. 检查网络连接:确保网络连接正常,排除网络问题导致的连接中断。 2. 重连机制:在客户端程序中实现重连机制,当连接中断时自动重新连接服务器。 3. 错误处理:在客户端程序中捕获并处理异常,例如记录日志、提示用户等。 4. 心跳机制:通过定时发送心跳消息来保持连接活跃,一旦连接中断可以及时发现并重新连接。 5. 优化代码和性能:确保客户端程序的代码质量和性能,减少程序错误和崩溃的可能性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值