2.x: @CheckReturnValue for public API

[vanniktech]

How do you guys feel if the @CheckReturnValue annotation was added to certain public API methods?

The one that would probably benefit the most in my opinion would be the subscribe method where you get a Subscription or Disposable back. In 99% of the cases you want to handle it.

Also static analyze tools such as Error Prone could emit an error / warning.

[akarnokd]

I frequently fire up subscribe(Consumer) and don't care about cancellation so it would just bother me. Also @CheckReturnValue sounds like part of some extra dependency and we don't want that. The only dependency is the Reactive-Streams API.

[vanniktech]

Yes either get the annotation from JSR 305 or I believe that creating our own annotation with the same name would also work.

[akarnokd]

I think subscribeWith is a reasonable target here as its purpose is to give you back what you gave to it so you can continue with that value. Also methods returning Flowable etc. shouldn't be ignored. If you can make it without external dependencies, I'm fine with the extra annotations.

[vanniktech]

Alright will give it a try soon.

[vanniktech]

Closing via #4881

[markelliot]

What's the rationale behind forcing handling of a Disposable return value? In most of the cases I've encountered I've preferred a setup where my subscription runs indefinitely. Is it unsafe to ignore the return here? If so, why?

[akarnokd]

@markelliot It was decided anything that returns Disposable should not have @CheckReturnValue. Did you find method(s) that do?

[markelliot]

I'm on 2.0.5 and the source for subscribe looks like this:

    @CheckReturnValue
    @SchedulerSupport(SchedulerSupport.NONE)
    public final Disposable subscribe(Consumer<? super T> onNext) {
        return subscribe(onNext, Functions.ERROR_CONSUMER, Functions.EMPTY_ACTION, Functions.emptyConsumer());
    }

[markelliot]

Can't link to the source since GH is truncating at ~10k lines, but it looks like on master the code is the same.