Question

我在Crashlytics上看到以下崩溃：

RxJavaPlugins.setErrorHandler(e -> { });

现在根据the official documentation，这是因为无法在某些rx链中的某个地方传递异常，因此异常不是隐藏它，而是通过引发崩溃来处理它。

我知道我可以通过使用

来避免这种行为

onError

但是我宁愿找到问题的根源。但是，在异常日志中的任何地方我都看不到导致此问题的实际api请求或方法调用，只有来自Rx和Okhttp / retrofit的堆栈跟踪。

我的应用程序很大，因此我必须浏览所有存储库以查看可能错过了{{1}}处理的地方。

是否有更好的方法来调试此问题？

Answer 1

正如问题评论中所述，我不得不处理类似的问题。我们的问题出在我们的Android应用程序中。网络通话将花费很长时间，并且用户会将应用程序发送到后台。发生这种情况时，我们将处理订阅。当套接字超时发生时，没有人在监听异常，这会导致UndeliverableException。

我们已将默认错误处理程序替换为（在kotlin中，我希望可以）：

private object DefaultErrorHandler : Consumer<Throwable> {
  override fun accept(t: Throwable) {
    when (t) {
        is UndeliverableException -> accept(t.cause!!)
        is NullPointerException,
        is IllegalArgumentException -> Thread.currentThread().run {
            uncaughtExceptionHandler.uncaughtException(this, t)
        }
        else -> // Swallow the exception here. We logged it to Crashlytics...
    }
  }
}

val defaultErrorHandler: Consumer<Throwable> = DefaultErrorHandler

// Then on application start we would replace the error handler
RxJavaPlugins.setErrorHandler(defaultErrorHandler)

我很确定defaultErrorHandler是一个可怕的名字。抱歉。

一些解释。我们不接受的例外是NullPointerException和IllegalArgumentException。这些被转发到当前线程的未捕获异常处理程序。我们这样做是因为这些通常与编程错误有关。

我们检查UndeliverableExceptions并解开它们，以再次通过同一使用者重新运行。这只是为了确保我们针对无法交付的异常运行正确的逻辑。

所有其他异常均被吞入并登录到crashlytics中以进行进一步评估。

一件关键的事情，这适用于我们的用例。可能是您需要对其进行调整。我并不是说这是最好的方法。这是一个例子。也许对您来说，您只想忽略套接字超时。

RxJava2 + OkHttp无法传递的异常：套接字超时

1 个答案: