Netty源码分析第四章: pipeline

第6节: 传播异常事件

讲完了inbound事件和outbound事件的传输流程, 这一小节剖析异常事件的传输流程

首先我们看一个最最简单的异常处理的场景:

@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());
}

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

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

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

我们跟到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);
}
}

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

我们跟到fireChannelRead方法中:

private void notifyHandlerException(Throwable cause) {

    //代码省略

    invokeExceptionCaught(cause);
}

再继续跟到invokeExceptionCaught方法中:

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

走到这里一切都明白了, 这里调用了当前handler的exceptionCaught方法, 也就是我们重写的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节点开始的

跟进invokeExceptionCaught方法:

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中的方法:

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

这里又是我们熟悉的逻辑, 调用当前handler的exceptionCaught方法, 因为当前handler是head, 所以首先会调用headContext的exceptionCaught方法

跟进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方法:

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

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

跟到invokeExceptionCaught方法中:

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中执行了next的exceptionCaught, 这里的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);
}

我们看到最终这里释放了异常对象

以上就是有关异常事件的传播

上一节: 传播outbound事件

下一节: 前章节内容回顾

Netty源码分析第4章(pipeline)---->第6节: 传播异常事件的更多相关文章

  1. Netty源码分析第4章(pipeline)---->第4节: 传播inbound事件

    Netty源码分析第四章: pipeline 第四节: 传播inbound事件 有关于inbound事件, 在概述中做过简单的介绍, 就是以自己为基准, 流向自己的事件, 比如最常见的channelR ...

  2. Netty源码分析第4章(pipeline)---->第5节: 传播outbound事件

    Netty源码分析第五章: pipeline 第五节: 传播outBound事件 了解了inbound事件的传播过程, 对于学习outbound事件传输的流程, 也不会太困难 在我们业务代码中, 有可 ...

  3. Netty源码分析第4章(pipeline)---->第7节: 前章节内容回顾

    Netty源码分析第四章: pipeline 第七节: 前章节内容回顾 我们在第一章和第三章中, 遗留了很多有关事件传输的相关逻辑, 这里带大家一一回顾 首先看两个问题: 1.在客户端接入的时候, N ...

  4. Netty源码分析第4章(pipeline)---->第1节: pipeline的创建

    Netty源码分析第四章: pipeline 概述: pipeline, 顾名思义, 就是管道的意思, 在netty中, 事件在pipeline中传输, 用户可以中断事件, 添加自己的事件处理逻辑, ...

  5. Netty源码分析第4章(pipeline)---->第2节: handler的添加

    Netty源码分析第四章: pipeline 第二节: Handler的添加 添加handler, 我们以用户代码为例进行剖析: .childHandler(new ChannelInitialize ...

  6. Netty源码分析第4章(pipeline)---->第3节: handler的删除

    Netty源码分析第四章: pipeline 第三节: handler的删除 上一小节我们学习了添加handler的逻辑操作, 这一小节我们学习删除handler的相关逻辑 如果用户在业务逻辑中进行c ...

  7. Netty源码分析第2章(NioEventLoop)---->第7节: 处理IO事件

    Netty源码分析第二章: NioEventLoop   第七节:处理IO事件 上一小节我们了解了执行select()操作的相关逻辑, 这一小节我们继续学习select()之后, 轮询到io事件的相关 ...

  8. Netty源码分析第5章(ByteBuf)---->第10节: SocketChannel读取数据过程

    Netty源码分析第五章: ByteBuf 第十节: SocketChannel读取数据过程 我们第三章分析过客户端接入的流程, 这一小节带大家剖析客户端发送数据, Server读取数据的流程: 首先 ...

  9. Netty源码分析第5章(ByteBuf)---->第4节: PooledByteBufAllocator简述

    Netty源码分析第五章: ByteBuf 第四节: PooledByteBufAllocator简述 上一小节简单介绍了ByteBufAllocator以及其子类UnPooledByteBufAll ...

随机推荐

  1. 将项目发布到Maven中央仓库的不完整纪要

    背景 有几个Utils性质的Jar需要跨项目引用,原本想部署私有Maven仓库,后来感觉太麻烦,索性直接发布到中央库,引用时也方便. 发布成功之后,觉得某些细节还是有必要记录一下. 资源 Sonaty ...

  2. Day7 Tomcat和servlet

    web服务器 1)        什么是web服务器 硬件:性能强大的计算机(无显示屏) 操作系统: linux 软件:web服务器软件(将数据放置在服务器上就可以被外部访问) web应用程序 2)  ...

  3. kubernetes API Server 权限管理实践

    API Server权限控制方式介绍 API Server权限控制分为三种:Authentication(身份认证).Authorization(授权).AdmissionControl(准入控制). ...

  4. TensorFlow安装-Windows

    参考:https://blog.csdn.net/dou3516/article/details/77836459 一.安装环境 TensorFlow即可以支持CPU,也可以支持CPU+GPU.前者的 ...

  5. 关于jquery的click()方法

    昨天,有个同事研究了以下jqury的click()方法,代码如下: <!DOCTYPE html> <html> <head> <meta charset=& ...

  6. ASP.NET MVC中Section、Partial View 和 Child Action(转载)

    概括的讲,View中的内容可以分为静态和动态两部分.静态内容一般是html元素,而动态内容指的是在应用程序运行的时候动态创建的内容.给View添加动态内容的方式可归纳为下面几种: Inline cod ...

  7. Hbase-0.96.2全然分布式安装部署

    Hbase-0.96.2全然分布式安装部署 环境: Hadoop-2.2.0 Zookeeper-3.4.6 hbase-0.96.2 1.下载hbase-0.96.2-hadoop2-bin.tar ...

  8. UOJ#206. 【APIO2016】Gap(交互,乱搞)

    描述 提交 自定义测试 有 NN 个严格递增的非负整数 a1,a2,…,aNa1,a2,…,aN(0≤a1<a2<⋯<aN≤10180≤a1<a2<⋯<aN≤101 ...

  9. mysql/mariadb学习记录——查询3(AVG、SUM、COUNT)函数

    AVG() 求平均数函数: //求emp表中的sal属性的平均值 mysql> select avg(sal) as salAverage from emp; +-------------+ | ...

  10. 安装好XAMPP+安装好PhpStorm 然后搭建PHP开发环境

    1.安装XAMPP 1.1.可以参考我的这篇博客:XMAPP的安装与配置. 2.安装并破解PhpStorm 2.1.可以参考我的这篇博客:PhpStorm2016.2版本安装与破解. 3.配置PhpS ...