These are chat archives for ReactiveX/RxJava
RxJava – Reactive Extensions for the JVM – a library for composing asynchronous and event-based programs using observable sequences for the Java VM.
Cancellableare logically equivalent.
Cancellable.cancel()allows the implementor to throw a checked exception. They are there to allow resource cleanup when the emitter is terminated or cancelled.
doFinallyactually. It is on purpose because most use cases involving a resource would leak that resource when the generator terminates. It sounds like you used the wrong abstraction or didn't properly anticipate the sharing of that request state.
setDisposable. The behavior then is provided by the Emitter. I don't see any case for misleading naming, just misunderstanding. The main use case for
setCancellableis to release resources created within the emitter callback which are scoped for the duration of the emission. If you have external resources that are shared, you'll need other means to release them considering how a solution would interact with it.
The governing rule here is 1.6:
"If a Publisher signals either onError or onComplete on a Subscriber, that Subscriber’s Subscription MUST be considered cancelled.
The intent of this rule is to make sure that a Subscription is treated the same no matter if it was cancelled, the Publisher signalled onError or onComplete."
People coming from different backgrounds tend to get confused by different naming. There is often discussion how to name components so that it doesn't imply too much but doesn't go under the radar either.
setCancellable follows the typical bean-setter naming indicating you set some object on this emitter.