Throwing exceptions

[gregw]

The specification says in 1.9:

Publisher.subscribe MUST call onSubscribe on the provided Subscriber prior to any other signals to that Subscriber and MUST return normally, except when the provided Subscriber is null in which case it MUST throw a java.lang.NullPointerException to the caller, for all other situations the only legal way to signal failure (or reject the Subscriber) is by calling onError (after calling onSubscribe).

and in 2.13:

Calling onSubscribe, onNext, onError or onComplete MUST return normally except when any provided parameter is null in which case it MUST throw a java.lang.NullPointerException to the caller, for all other situations the only legal way for a Subscriber to signal failure is by cancelling its Subscription. 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.

I think this is too restrictive and impossible to implement. Almost any arbitrary java code may through an unchecked exception (out of memory, interrupted, etc.) so even an implementation that catches Throwable may throw in it's handling of the caught exception.

Attempts to rigorously implement 1.9 and 2.13 have resulted in discussions like #271 which are motivated as the calling of cancel is often an insufficient signal for unexpected events.

Instead, I think that the language should be changed so that exceptions MAY be thrown from these methods, but that such exceptions are fatal and are not guaranteed to be passed up or down to the subscriber. I know that is essentially what "legal" means, but there is a slight change of emphasis as it means implementations do not have to obsess about catching OOM etc.

[smaldini]

I think the spec precise non fatal exception.

Sent from my iPhone

On 15 Sep 2015, at 10:01 pm, Greg Wilkins [email protected] wrote:

The specification says in 1.9:

Publisher.subscribe MUST call onSubscribe on the provided Subscriber prior to any other signals to that Subscriber and MUST return normally, except when the provided Subscriber is null in which case it MUST throw a java.lang.NullPointerException to the caller, for all other situations the only legal way to signal failure (or reject the Subscriber) is by calling onError (after calling onSubscribe).
and in 2.13:

Calling onSubscribe, onNext, onError or onComplete MUST return normally except when any provided parameter is null in which case it MUST throw a java.lang.NullPointerException to the caller, for all other situations the only legal way for a Subscriber to signal failure is by cancelling its Subscription. 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.
I think this is too restrictive and impossible to implement. Almost any arbitrary java code may through an unchecked exception (out of memory, interrupted, etc.) so even an implementation that catches Throwable may throw in it's handling of the caught exception.

Attempts to rigorously implement 1.9 and 2.13 have resulted in discussions like #271 which are motivated as the calling of cancel is often an insufficient signal for unexpected events.

Instead, I think that the language should be changed so that exceptions MAY be thrown from these methods, but that such exceptions are fatal and are not guaranteed to be passed up or down to the subscriber. I know that is essentially what "legal" means, but there is a slight change of emphasis as it means implementations do not have to obsess about catching OOM etc.

—
Reply to this email directly or view it on GitHub.

[smaldini]

And input error (NPE).

Sent from my iPhone

On 15 Sep 2015, at 10:01 pm, Greg Wilkins [email protected] wrote:

The specification says in 1.9:

Publisher.subscribe MUST call onSubscribe on the provided Subscriber prior to any other signals to that Subscriber and MUST return normally, except when the provided Subscriber is null in which case it MUST throw a java.lang.NullPointerException to the caller, for all other situations the only legal way to signal failure (or reject the Subscriber) is by calling onError (after calling onSubscribe).
and in 2.13:

Calling onSubscribe, onNext, onError or onComplete MUST return normally except when any provided parameter is null in which case it MUST throw a java.lang.NullPointerException to the caller, for all other situations the only legal way for a Subscriber to signal failure is by cancelling its Subscription. 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.
I think this is too restrictive and impossible to implement. Almost any arbitrary java code may through an unchecked exception (out of memory, interrupted, etc.) so even an implementation that catches Throwable may throw in it's handling of the caught exception.

Attempts to rigorously implement 1.9 and 2.13 have resulted in discussions like #271 which are motivated as the calling of cancel is often an insufficient signal for unexpected events.

Instead, I think that the language should be changed so that exceptions MAY be thrown from these methods, but that such exceptions are fatal and are not guaranteed to be passed up or down to the subscriber. I know that is essentially what "legal" means, but there is a slight change of emphasis as it means implementations do not have to obsess about catching OOM etc.

—
Reply to this email directly or view it on GitHub.

[viktorklang]

Sounds resolved, reopen if not. Thank you