[concurrency-interest] Upcoming jdk9 j.u.c JEP

Greg Wilkins gregw at webtide.com
Fri Jul 24 17:59:43 EDT 2015


Note that the specification
says that onNext should not throw an exception:

*"the only legal way for a Subscriber to signal failure is by cancelling
its Subscription"*

However it also specifies what to do if that rule is broken:

*In the case that this rule is violated, any associated Subscription to the
Subscriber MUST be considered as cancelled, and the caller MUST raise this
error condition in a fashion that is adequate for the runtime environment*

So as there is no other legal outlet for failures in a subscriber, I'm
guessing that lots of implementations will just throw unchecked exceptions
from onNext (no point catching them if you have nothing you can do with
them) and SubmissionPublisher needs to be able to deal with it....   which
it currently does by feeding the exception back downstream by calling

I would think that it should call cancel() and then notify with a callback
like you suggest (or perhaps the default onSubscriberException
implementation should be cancel?).

So yes, I think the impl needs to be improved in this regards, but I also
think this is a good example how not having a proper outlet for subscriber
failures in the spec has confused an implementation.... but I'll take that
discussion back to the issue.


On 25 July 2015 at 06:26, Doug Lea <dl at cs.oswego.edu> wrote:

> I've been encouraging people to discuss spec issues at
>   https://github.com/reactive-streams/reactive-streams-jvm/issues
> just to keep them in one place.
> But this one might impact SubmissionPublisher (a potential j.u.c
> class, not the spec itself):
> On 07/23/2015 06:35 PM, Greg Wilkins wrote:
>  Specifically that it is asymmetric and an error in the
>> middle of a chain of processors can be propagated downstream with
>> onError(Throwable) but can only be propagated upstream with cancel().
> If a call to onNext throws an exception, the only thing guaranteed
> is that the subscription will be cancelled. (There are also some
> words saying that the Subscriber is at that point non-compliant.)
> But I don't see anything that stops any publisher/subscription
> from doing something with that exception before/during the
> cancellation. So should there be a SubmissionPublisher method
> along the lines of:
>   onSubscriberException(Consumer<? extends Throwable> handler);
> -Doug
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20150725/b826f786/attachment.html>

More information about the Concurrency-interest mailing list