Netty源碼分析第四章: pipelinehtml
第6節: 傳播異常事件ide
講完了inbound事件和outbound事件的傳輸流程, 這一小節剖析異常事件的傳輸流程oop
首先咱們看一個最最簡單的異常處理的場景:源碼分析
@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方法中被調用this
咱們跟到invokeChannelRead這個方法:spa
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方法, 並傳入異常對象, 也就是咱們示例中拋出的異常code
咱們跟到fireChannelRead方法中:htm
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); }
咱們看到最終這裏釋放了異常對象
以上就是有關異常事件的傳播