我们如何处理会议室生成的分页代码中的运行时错误？

如何解决我们如何处理会议室生成的分页代码中的运行时错误？

在this sample project中，我有a DAO正在使用FTS4表上的Paging 2通过用户提供的搜索表达式进行搜索：

  @Query("SELECT snippet(paragraphsFts) FROM paragraphs JOIN paragraphsFts "+
      "ON paragraphs.id == paragraphsFts.rowid WHERE paragraphsFts.prose "+
      "MATCH :search ORDER BY sequence")
  abstract fun filtered(search: String): DataSource.Factory<Int,String>

我有a BookRepository和一个filtered()函数，该函数只是通过对DAO的调用，并且我有a SearchViewModel将DataSource.Factory转换为{{1} }：

LiveData

我有a fragment观察结果：

class SearchViewModel(search: String,repo: BookRepository) : ViewModel() {
  val paragraphs = repo.filtered(search).toLiveData(pageSize = 15)
}

这很好，只要用户不输入语法错误的搜索表达式即可。在这种情况下，Room会引发异常，而我看不到在哪里可以捕捉到它。

    vm.paragraphs.observe(this.viewLifecycleOwner) {
      adapter.submitList(it)
    }

由2020-08-30 08:50:50.923 13948-14019 E/AndroidRuntime: FATAL EXCEPTION: arch_disk_io_3 Process: com.commonsware.room.pagedfts,PID: 13948 android.database.sqlite.SQLiteException: malformed MATCH expression: [-9] (code 1 SQLITE_ERROR) at android.database.sqlite.SQLiteConnection.nativeExecuteForCursorWindow(Native Method) at android.database.sqlite.SQLiteConnection.executeForCursorWindow(SQLiteConnection.java:942) at android.database.sqlite.SQLiteSession.executeForCursorWindow(SQLiteSession.java:838) at android.database.sqlite.SQLiteQuery.fillWindow(SQLiteQuery.java:62) at android.database.sqlite.SQLiteCursor.fillWindow(SQLiteCursor.java:153) at android.database.sqlite.SQLiteCursor.getCount(SQLiteCursor.java:140) at android.database.AbstractCursor.moveToPosition(AbstractCursor.java:232) at android.database.AbstractCursor.moveToFirst(AbstractCursor.java:271) at androidx.room.paging.LimitOffsetDataSource.countItems(LimitOffsetDataSource.java:89) at androidx.room.paging.LimitOffsetDataSource.loadInitial(LimitOffsetDataSource.java:119) at androidx.paging.PositionalDataSource.dispatchLoadInitial(PositionalDataSource.java:286) at androidx.paging.TiledPagedList.<init>(TiledPagedList.java:107) at androidx.paging.PagedList.create(PagedList.java:229) at androidx.paging.PagedList$Builder.build(PagedList.java:388) at androidx.paging.LivePagedListBuilder$1.compute(LivePagedListBuilder.java:206) at androidx.paging.LivePagedListBuilder$1.compute(LivePagedListBuilder.java:171) at androidx.lifecycle.ComputableLiveData$2.run(ComputableLiveData.java:101) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.lang.Thread.run(Thread.java:919) 创建的LiveData使用的后台线程上发生异常。因此，我的toLiveData()声明中的try / catch将不起作用，因为在创建paragraphs时不会引发异常。将我的LiveData调用包装在observe() / try中是行不通的，因为没有在该线程上引发异常。

如果我没有使用Paging，而是让我的DAO的catch函数是filtered()函数，我将直接获取异常并可以在viewmodel中捕获并处理它。或者，如果suspend是一个阻塞调用，我将直接获得异常。或者，如果filtered()返回了RxJava类型，我将通过普通的RxJava异常处理方法（例如filtered() lambdas）来获取异常。但是我不太清楚在使用Paging时应该在哪里拦截此异常。

尽管现在Paging 3仍处于Alpha状态，但Paging 3可能有解决方案，这很高兴知道。

虽然我还没有尝试过，但是我怀疑如果我向onError提供自己的Executor，那么我可以在那里捕获异常。即使这是一个可能的解决方法，似乎我也要依靠副作用（替换我们如何安排线程上的工作以捕获异常）。