没必要封装成库，小题大作了

[artshell]

用过compose操作符的人都应该知道这种 XXXTransformer 思路 请求成功的success info 与 请求失败的error info 对用户来说都是data，严格来说应该统一在main thread下的 subscribe(Consumer<? super T> onNext, Consumer<? super Throwable> onError)里指定callback就行，特别是 throwable，在ui层成判断哪些信息是需要友好展现给用户的，哪些是需要抛弃的（在debug调试阶段状态下打印出来）， 在中途把error信息抛出来，很容易出现在子线程上下文内去回调执行ui逻辑，这一点很容易让使用者陷入误区，同时应该避免在 upstream和downstream之间来回线程切换，项目明显用java实现后可读性更好，用kotlin去糊一道，完全是玩的心态....

[qingmei2]

@artshell

请求成功的success info 与 请求失败的error info 对用户来说都是data，严格来说应该统一在main thread下的 subscribe(Consumer<? super T> onNext, Consumer<? super Throwable> onError)里指定callback就行，特别是 throwable

这一点我还保持疑问，我一直在思考如何衡量 全局Error处理的粒度，什么样的Error在RxJava的流中可以被全局Handle统一处理，什么样的Error应该作为Activity或者Fragment级别的特殊处理，subscribe()方法是否可以仅作为Terminal级别的操作符，而不是重在onNext或者onError的回调中对业务的处理（subscribe()的滥用会破坏对流的控制）。

因此我目前对于subscribe(Consumer<? super T> onNext, Consumer<? super Throwable> onError)的理解可能更倾向于一次用户对UI的响应事件的最终处理，error的处理交给error相关的操作符,最终全局级别的error进行全局处理，作用域（比如Activity/Fragment）内的error交给作用域级别的error Handle处理，这样的实现方式于我而言可能更好用一些？

叙述能力有限，简单的代码实现大概是这样的： https://github.com/qingmei2/MVVM-Rhine/blob/master/app/src/main/java/com/qingmei2/sample/ui/login/LoginViewModel.kt

没必要封装成库，小题大作了

这个repo的意义就是在于展示如何使用Rx的操作符展示更ReactiveX的代码, 因为 不同的项目需求是不同的，不同的场景也会有更好的实现方式，目前我的这种方式我不认为它是完美的，因为它过于通用了。

因此，我很认同您的观点，我会在README中更新并声明这些——它本身的学习意义应该远远大于生产环境中使用的意义。

[artshell]

现在项目通常都用MVP模式，在V层实现Error处理就行（activity/fragment两处是同样逻辑）一般就是BaseActivity/BaseFragment

main thread下的subscribe（onNext， onError -> getView.handlerError(throwable) ）这样调用就行

看了下你给的链接，官网ViewModel这种方案对Net server接口数据请求处理方式太重了，官方也说了自己有好的实现方式就没必要用ViewModel + LiveData（MVP这套更强一点），ViewModel + LiveData更适合拿取本地数据、Fragment之间、activity之间通信。链接代码里使用了RxJava, arch里边已经提供的LiveDataReactiveStreams工具可以直接适配RxJava接口（不过 onError那里的实现方式也是从中途把Error抛给了Main线程，无奈）

[qingmei2]

@artshell

我明白了您的思路，这个repo中代码的本身其实就是想要规避过多的subscribe（onNext， onError -> getView.handlerError(throwable) ）可能会导致流的滥用，只要保证代码的规范性，我认为最终的思路都是趋同的哈。

感谢和您的讨论 🤝