-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider not calling onNext(null) #33
Comments
To add some context, the problem is that interfaces like This is then implemented by all concurrent queue implementations, like Java's own ConcurrentLinkedQueue, or the ones in JCTools.org. And reactive streams implementations, such as Monix, use concurrent queues to implement buffering on asynchronous boundaries, where needed. RxJava is also using the queue implementations in JCTools. Even if you've been allowed to push |
Here's another clearer reason for why |
Hi, you're correct, but due to backward compatibility I'm hesitant to change observables emitting a single null to Observable.empty(). But for example returning something like |
@alaisi if that's some kind of enum, then it sounds good. IMO the problem is that Observables aren't really meant for single values. Those are usually |
@alaisi - I'd say that's fine, just note you still have a compat issue if people saved off the |
Ok, great. For Single, that will probably be taken into using when porting to RxJava 2.0. |
For any others, note, this is causing me production issues at postgres-async-driver/src/main/java/com/github/pgasync/impl/netty/NettyPgProtocolStream.java Line 304 in 71e761c
Not really sure what to do about it (working on moving to another lib) but figured I'd post the stack trace to help anyone else Googling. |
Null values can be difficult for different reactive streams implementations to handle (e.g. monix/monix#252). I understand it can cause compatibility concerns, but possibly changing
com.github.pgasync.Transaction::commit
to returnObservable<?>
orObservable<Object>
instead ofObservable<Void>
and return something likeOptional.empty()
may be cleaner (and apply the same thing to other places whereonNext(null)
is invoked).The text was updated successfully, but these errors were encountered: