问题引入

代码示例如下

通过 EventBus 发送一个 MyEvent 事件，然后在接收事件的地方调用 Class.forName 后，问题现象是：forName 函数接下来所有的函数调用都没有执行，并且没有任何crash 堆栈。

//发送Event
EventBus.getDefault().post(MyEvent())


//接受Event
@Subscribe(threadMode = ThreadMode.MAIN)
fun onEvent(event:MyEvent){
    //这里一系列的函数调用，最终调用到 testError 函数
    testError()
}


fun testError(){
    try{
        val clazz = Class.forName("xxx")

        //其它函数调用
    }catch(e:Exception){
        e.printStackTrace()
    }

}

开始分析

客诉反馈问题，我们最后复现定位到 testError 函数这里，但是没有进入 catch 块中，这是为什么呢？

是不是 EventBus 捕获了这个 NoSuchFieldError？

testError 函数是 EventBus 中调用的，但是从 EventBus 内部的代码 invokeSubscriber 就是发送事件到订阅者的，并没有 catch 相关的 Exception 这就很奇怪了。

因此我选择断点的方式来调试，发现进入的 InvocationTargetException 这个异常捕获里面

进入处理该异常的方法 handleSubscriberException 一探究竟

问题发现了，很明显，logSubscriberExceptions 这个参数是 false，WTF，哪个沙雕在项目中配置了 false 的。

于是我去项目中找到了这段配置，真是一万个草泥马，就是因为这个导致异常被 EventBus 内部消化了，没有任何的打印信息。

EventBus.builder()
.sendNoSubscriberEvent(BuildConfig.DEBUG)
.logNoSubscriberMessages(BuildConfig.DEBUG)
.logSubscriberExceptions(BuildConfig.DEBUG)// release 包居然把这个关闭了，怪不得，怪不得
.installDefaultEventBus();

为什么会被 InvocationTargetException 捕获了呢？

我尝试分析了 EventBus 是如何将事件分发给订阅者的，从上图中的 invokeSubscriber 中很明显，异常被 InvocationTargetException 捕获了，这个异常就是反射调用时产生的异常，我们来深入看看为什么 testError 中产生的异常最终会变成这个 InvocationTargetException

反射异常InvocationTargetException

为了验证这个问题，我写一个 demo 来验证看看：
在如下的代码中，点击事件内部去调用 "testThrowError" 方法，并且该方法内部抛出 NoSuchFieldError 错误，按照正常理解，整个程序肯定是 crash 了，但是实际上并没有，程序正常运行，并且捕获到了 InvocationTargetException 异常，你说奇不奇怪呢？

textView.setOnClickListener {
    Log.e("MainActivity", "click")
    try {
        AA::class.java.getDeclaredMethod("testThrowError").invoke(this)
    }catch (e:InvocationTargetException){
        Log.e("AA", "InvocationTargetException:${e.cause}")
        e.printStackTrace()
    }
}

fun testThrowError() {
    throw NoSuchFieldError("click")
}

来看看异常堆栈哦：

啧，这费解了🤔...

于是我打开 Method 类，想看看 invoke 函数是如何实现，但是事与愿违，是 native 的实现。

native 如何调用 invoke 函数？

根据异常的 InvocationTargetException 名字，我反推这个异常创建的地方，也就是下图这里。

我来解释一下，在 invokeMethodImpl 中，会将调用 invoke 中产生的异常进行包装成
InvocationTargetException ：Wrap any excetion with "Ljava/lang/reflect/InvocationTargetException" .... 嗯，看到源码这句注释应该就大概知道为什么会返回这个异常了吧。

下面来梳理一下创建InvocationTargetException的过程：
● 首先，它会获取当前发生的异常（包括 Error 类型也会被获取到），这个异常是通过soa.Env()->ExceptionOccurred()获取的。
● 然后，它会清除当前的异常，这是通过soa.Self()->ClearException()完成的。
● 接着，它会创建一个新的InvocationTargetException实例。这是通过调用soa.Env()->NewObject方法完成的，这个方法接受InvocationTargetException的类对象，构造器方法对象，以及原始的异常对象(这个原始异常对象就是被包装的那个异常 cause)。
● 最后，如果InvocationTargetException实例创建成功，它会将这个新的异常抛出。这是通过调用soa.Env()->Throw方法完成的。

所以，看到这里就明白了，为什么发送 EventBus 后在接收事件的地方出现异常并不会出现 crash 就是这个原因呢。

总结几点

1. EventBus 的日志一定要打开，不然排查问题真的很要命
2. 反射 Method.invode 方法记得要处理InvocationTargetException 然后获取该异常的 e.getCause() 得到包装的异常，就像 EventBus 源码就针对这个异常做了处理的