netty中pipeline异常事件分析

目录
  • 异常处理的场景
  • AbstractChannelHandlerContext.invokeChannelRead
    • AbstractChannelHandlerContext.notifyHandlerException(Throwable cause)
      • AbstractChannelHandlerContext.invokeExceptionCaught(final Throwable cause)
  • 两种写法
    • DefualtChannelPipeline.fireExceptionCaught
      • AbstractChannelHandlerContext.invokeExceptionCaught(head, cause)
      • AbstractChannelHandlerContext.invokeExceptionCaught(cause)
      • exceptionCaught方法
      • AbstractChannelHandlerContex.fireExceptionCaught
      • AbstractChannelHandlerContex.invokeExceptionCaught(next, cause)
      • 我们以ChannelInboundHandlerAdapter为例看它的该方法实现
      • 我们跟到TailConext的exceptionCaught方法

异常处理的场景

@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
    throw new Exception("throw Exception");
}
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
    System.out.println(cause.getMessage());
}

我们在handlerchannelRead方法中主动抛出异常, 模拟程序中出现异常的场景, 经测试会发现, 程序最终会走到exceptionCaught方法中, 获取异常对象并打印其信息

那么抛出异常之后, 是如何走到exceptionCaught方法的呢?

我们回顾之前小节channelRead事件的传播流程, channelRead方法是在AbstractChannelHandlerContext类的invokeChannelRead方法中被调用

AbstractChannelHandlerContext.invokeChannelRead

private void invokeChannelRead(Object msg) {
    if (invokeHandler()) {
        try {
            //调用了当前handler的channelRead方法, 其实就是head对象调用自身的channelRead方法
            ((ChannelInboundHandler) handler()).channelRead(this, msg);
        } catch (Throwable t) {
            //发生异常的时候在这里捕获异常
            notifyHandlerException(t);
        }
    } else {
        fireChannelRead(msg);
    }
}

这里不难看出, 当调用户自定义的handlerchannelRead方法发生异常之后, 会被捕获, 并调用notifyHandlerException方法, 并传入异常对象, 也就是我们示例中抛出的异常

AbstractChannelHandlerContext.notifyHandlerException(Throwable cause)

private void notifyHandlerException(Throwable cause) {
    //代码省略
    invokeExceptionCaught(cause);
}

AbstractChannelHandlerContext.invokeExceptionCaught(final Throwable cause)

private void invokeExceptionCaught(final Throwable cause) {
    if (invokeHandler()) {
        try {
            //当前handler调用exceptionCaught()方法
            handler().exceptionCaught(this, cause);
        } catch (Throwable error) {
            //代码省略
        }
    } else {
        fireExceptionCaught(cause);
    }
}

走到这里一切都明白了, 这里调用了当前handlerexceptionCaught方法, 也就是我们重写的exceptionCaught方法

知道了为什么会走到exceptionCaught方法之后, 我们再进行剖析异常事件的传播流程

两种写法

@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
    System.out.println(cause.getMessage());
}
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
    //写法1
    ctx.fireChannelRead(cause);
    //写法2
    ctx.pipeline().fireExceptionCaught(cause);
}

这两种写法我们并不陌生, 可能我们能直接猜到, 第一种写法是从当前节点进行传播, 第二种写法则从头结点或者尾节点进行转播, 那么和传播inbound事件或outbound事件有什么区别呢?我们先以第二种写法为例, 剖析异常事件传输的整个流程

DefualtChannelPipeline.fireExceptionCaught

public final ChannelPipeline fireExceptionCaught(Throwable cause) {
    AbstractChannelHandlerContext.invokeExceptionCaught(head, cause);
    return this;
}

我们看到invokeExceptionCaught传入了head节点, 我们可以猜测, 异常事件的传播是从head节点开始的

AbstractChannelHandlerContext.invokeExceptionCaught(head, cause)

static void invokeExceptionCaught(final AbstractChannelHandlerContext next, final Throwable cause) {
    ObjectUtil.checkNotNull(cause, "cause");
    EventExecutor executor = next.executor();
    if (executor.inEventLoop()) {
        //执行下一个节点的异常方法
        next.invokeExceptionCaught(cause);
    } else {
        try {
            executor.execute(new Runnable() {
                @Override
                public void run() {
                    next.invokeExceptionCaught(cause);
                }
            });
        } catch (Throwable t) {
            //忽略代码
        }
    }
}

因为这里是传入的是head节点, 所以这里的next指向head节点。

我们跟到invokeExceptionCaught方法中, 这里其实是headContext的父类AbstractChannelHandlerContext中的方法

AbstractChannelHandlerContext.invokeExceptionCaught(cause)

private void invokeExceptionCaught(final Throwable cause) {
    if (invokeHandler()) {
        try {
            //当前handler调用exceptionCaught()方法
            handler().exceptionCaught(this, cause);
        } catch (Throwable error) {
            //代码省略
        }
    } else {
        fireExceptionCaught(cause);
    }
}

这里又是我们熟悉的逻辑, 调用当前handlerexceptionCaught方法, 因为当前handlerhead, 所以首先会调用headContextexceptionCaught方法

exceptionCaught方法

public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
    ctx.fireExceptionCaught(cause);
}

这里仅仅是继续传播异常事件, 这时候我们发现, 这个写法和我们刚才提到传播异常事件的两种写法的第一种写法一样

@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
    //写法1
    ctx.fireChannelRead(cause);
    //写法2
    ctx.pipeline().fireExceptionCaught(cause);
}

根据我们之前的学习, 我们知道第一种写法是从当前节点传播, 而第二种写法是从头传播, 并且要求传播事件一定要使用第一种写法, 否则事件到这里会重新从头传播进而引发不可预知错误, 这个结论在异常传播同样适用, 同学们一定要注意这点

我们继续跟fireExceptionCaught方法, 这里会走到AbstractChannelHandlerContex类的fireExceptionCaught方法

AbstractChannelHandlerContex.fireExceptionCaught

public ChannelHandlerContext fireExceptionCaught(final Throwable cause) {
    //传播异常事件的时候, 直接拿了当前节点的下一个节点
    invokeExceptionCaught(next, cause);
    return this;
}

这个时候我们发现, 这里并没有去获取下一个的inbound节点还是outbound节点, 而是直接通过next拿到下一个节点, 这就说明在异常事件传播的过程中是不区分inbound事件还是outbound事件的, 都是直接从head节点按照链表结构往下传播

AbstractChannelHandlerContex.invokeExceptionCaught(next, cause)

static void invokeExceptionCaught(final AbstractChannelHandlerContext next, final Throwable cause) {
    ObjectUtil.checkNotNull(cause, "cause");
    EventExecutor executor = next.executor();
    if (executor.inEventLoop()) {
        next.invokeExceptionCaught(cause);
    } else {
        try {
            executor.execute(new Runnable() {
                @Override
                public void run() {
                    next.invokeExceptionCaught(cause);
                }
            });
        } catch (Throwable t) {
            //代码省略
        }
    }
}

这里又是我们熟悉的逻辑, 我们知道invokeExceptionCaught中执行了nextexceptionCaught, 这里的next, 因为我们是从head节点开始剖析的, 所以这里很有可能就是用户自定义的handler, 如果用户没有重写exceptionCaught方法, 则会交给用户handler的父类处理

我们以ChannelInboundHandlerAdapter为例看它的该方法实现

public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause)
        throws Exception {
    ctx.fireExceptionCaught(cause);
}

我们看到这里继续向下传播了异常事件

走到这里我们会知道, 如果我们没有重写exceptionCaught方法, 异常事件会一直传播到链表的底部, 就是tail节点

我们跟到TailConext的exceptionCaught方法

public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
    onUnhandledInboundException(cause);
}

我们看到最终这里释放了异常对象,以上就是netty中pipeline异常事件分析的详细内容,更多关于netty pipeline异常事件的资料请关注我们其它相关文章!

(0)

相关推荐

  • Netty分布式pipeline管道传播事件的逻辑总结分析

    目录 问题分析 首先完成了handler的添加, 但是并没有马上执行回调 回到callHandlerCallbackLater方法中 章节总结 我们在第一章和第三章中, 遗留了很多有关事件传输的相关逻辑, 这里带大家一一回顾 问题分析 首先看两个问题: 1.在客户端接入的时候, NioMessageUnsafe的read方法中pipeline.fireChannelRead(readBuf.get(i))为什么会调用到ServerBootstrap的内部类ServerBootstrapAccep

  • Netty分布式pipeline管道Handler的删除逻辑操作

    目录 删除handler操作 我们跟到getContextPrDie这个方法中 首先要断言删除的节点不能是tail和head 回到remove(ctx)方法 上一小节我们学习了添加handler的逻辑操作, 这一小节我们学习删除handler的相关逻辑 删除handler操作 如果用户在业务逻辑中进行ctx.pipeline().remove(this)这样的写法, 或者ch.pipeline().remove(new SimpleHandler())这样的写法, 则就是对handler进行删除

  • netty服务端处理请求联合pipeline分析

    目录 两个问题 NioMessageUnsafe.read() ServerBootstrap.init(Channel channel) ChannelInitializer的继承关系 PendingHandlerAddedTask构造方法 PendingHandlerCallback构造方法 回到callHandlerCallbackLater方法 AbstractChannel.register0(ChannelPromise promise) pipeline.invokeHandler

  • Netty分布式pipeline管道异常传播事件源码解析

    目录 传播异常事件 简单的异常处理的场景 我们跟到invokeChannelRead这个方法 我还是通过两种写法来进行剖析 跟进invokeExceptionCaught方法 跟到invokeExceptionCaught方法中 讲完了inbound事件和outbound事件的传输流程, 这一小节剖析异常事件的传输流程 传播异常事件 简单的异常处理的场景 @Override public void channelRead(ChannelHandlerContext ctx, Object msg

  • netty中pipeline的handler添加删除分析

    目录 添加 DefaultChannelPipeline.addLast(ChannelHandler... handlers) checkMultiplicity(handler)重复添加验证 isSharable() newCtx = newContext(group, filterName(name, handler), handler) filterName(name, handler) checkDuplicateName(name) context0(name) newContext

  • Netty分布式pipeline管道传播outBound事件源码解析

    目录 outbound事件传输流程 这里我们同样给出两种写法 跟到其write方法中: 跟到findContextOutbound中 回到write方法: 继续跟invokeWrite0 我们跟到HeadContext的write方法中 了解了inbound事件的传播过程, 对于学习outbound事件传输的流程, 也不会太困难 outbound事件传输流程 在我们业务代码中, 有可能使用wirte方法往写数据: public void channelActive(ChannelHandlerC

  • netty pipeline中的inbound和outbound事件传播分析

    目录 传播inbound事件 两种写法 DefaultChannelPipeline.fireChannelRead(msg) AbstractChannelHandlerContext.invokeChannelRead(head, msg) AbstractChannelHandlerContext.invokeChannelRead(m) HeadContext的channelRead方法 AbstractChannelHandlerContext.fireChannelRead(msg)

  • Netty分布式pipeline管道Handler的添加代码跟踪解析

    目录 添加handler 我们跟到其addLast()方法中 再继续跟到addLast()方法中去 我们跟到checkMultiplicity(handler)中 跟到filterName方法中 跟到isInbound(handler)方法中 我们回到最初的addLast()方法中 我们跟进addLast0(newCtx)中 前文传送门:Netty分布式pipeline管道创建 添加handler 我们以用户代码为例进行剖析: .childHandler(new ChannelInitializ

  • 触屏中的JavaScript事件分析

    本文实例讲述了触屏中的JavaScript事件.分享给大家供大家参考.具体分析如下: 一.触摸事件 ontouchstart ontouchmove ontouchend ontouchcancel目前移动端浏览器均支持这4个触摸事件,包括IE.由于触屏也支持MouseEvent,因此他们的顺序是需要注意的:touchstart → mouseover → mousemove → mousedown → mouseup → click1 实例如下: /** * onTouchEvent */ v

  • Python中的异常类型及处理方式示例详解

    目录 前言 正文 一.什么是异常 二.异常的类型 三.异常处理 四.try 介绍 五.finally 介绍 六.raise 介绍 结尾 前言 Python 是一种面向对象的.解释型的.通用的.开源的脚本编程语言.现在市面上 Python 非常的流行,主要是因为它简单易用,学习成本低,比如要实现某个功能,Python 可能只需要几行代码,而用C语言可能需要上百行代码,因为C语言什么都要得从头开始编码,而 Python 已经内置了很多功能模块,所以,我们只需要导入特定的包,就可以实现想要的效果. 正

  • Netty分布式pipeline传播inbound事件源码分析

    前一小结回顾:pipeline管道Handler删除 传播inbound事件 有关于inbound事件, 在概述中做过简单的介绍, 就是以自己为基准, 流向自己的事件, 比如最常见的channelRead事件, 就是对方发来数据流的所触发的事件, 己方要对这些数据进行处理, 这一小节, 以激活channelRead为例讲解有关inbound事件的处理流程 在业务代码中, 我们自己的handler往往会通过重写channelRead方法来处理对方发来的数据, 那么对方发来的数据是如何走到chann

  • .NET中的异常和异常处理用法分析

    本文较为详细的分析了.NET中的异常和异常处理用法.分享给大家供大家参考.具体分析如下: .NET中的异常(Exception) .net中的中异常的父类是Exception,大多数异常一般继承自Exception. 可以通过编写一个继承自Exception的类的方式,自定义异常类! 异常处理机制: 复制代码 代码如下: Try {     //可能发生异常的代码     //后续代码     } //Try以外的代码 catch(Exception e) { } finally { } 上述代

  • JavaScript中的模拟事件和自定义事件实例分析

    本文实例讲述了JavaScript中的模拟事件和自定义事件.分享给大家供大家参考,具体如下: 前面介绍了JavaScript中为事件指定处理程序的五种方式和JavaScript的事件对象event. 下面介绍JavaScript中的模拟事件和自定义事件. 1.DOM中的事件模拟 1) DOM中的事件模拟有以下3个步骤: 步骤1:创建事件对象event 可以在document对象上使用createEvent()方法创建event对象,此方法接收一个参数,即要创建的事件类型的字符串.在DOM2级中这

  • JQuery中的常用事件、对象属性与使用方法分析

    本文实例讲述了JQuery中的常用事件.对象属性与使用方法.分享给大家供大家参考,具体如下: JQuery中的常用事件 .click() 鼠标单击触发事件,参数可选(data,function) .dblclick() 双击触发,同上 .mousedown()/up() 鼠标按下/弹起触发事件 .mousemove() 鼠标移动事件 .mouseover()/out() 鼠标移入/移出触发事件 .mouseenter()/leave() 鼠标进入/离开触发事件* .hover(func1,fun

  • Netty分布式pipeline管道创建方法跟踪解析

    目录 概述 pipeline的创建 上一章节回顾:Netty分布式源码分析监听读事件 概述 pipeline, 顾名思义, 就是管道的意思, 在netty中, 事件在pipeline中传输, 用户可以中断事件, 添加自己的事件处理逻辑, 可以直接将事件中断不再往下传输, 同样可以改变管道的流向, 传递其他事件.这里有点类似于Spring的AOP, 但是比AOP实现起来简单的多 事件通常分为两种, 一是inBound事件, 另一种是outBound事件, inBound事件, 顾名思义, 就是从另

随机推荐