add provisions for failing onError

[rkuhn]

discussion was:

@benjchristensen 2.13

We say nothing about onError failing and throwing an exception. We should add something like:

A failing onError (e.g. throwing an exception) is a specification violation and the Publisher or Subscription MUST throw (or wrap and re-throw) the thrown exception.

@smaldini

Well that could be a not but it didn't enforce anything so I didn't think about leaving it. WDYT ? Note or Rule ?

@benjchristensen

I think it's better to call this one out explicitly as it is important for people to have clarity on how the edge cases of error handling should be handled. In other words, I see it as proactively avoiding the FAQ about what "the right thing to do" is for this case.

A note would be fine, but since we already have 1.13, it feels natural in reading order to have the very next one explains what to do if onError fails, thus I'd suggest putting it as a rule ... it just happens to be a rule that you achieve naturally as long as you don't do anything actively wrong (swallowing errors for example).

@rkuhn

We need to define what it means for the Publisher–Subscriber (and possibly Subscription if one was created) for onError to throw, but defining the part of the behavior that is external to this relationship cannot meaningfully be covered by this spec—requiring to re-throw is only valid in certain scenarios, other implementations might have different mechanisms in place to deal with this. My proposal is:

A failing onError invocation is a violation of the specification. In this case the Publisher MUST consider a possible Subscription for this Subscriber as canceled. The Publisher SHOULD raise this error condition in a fashion that is adequate for the runtime environment (e.g. by throwing an exception, notifying a supervisor, logging, etc.).

[benjchristensen]

Original discussion: #61 (comment)

[viktorklang]

"A failing onError invocation is a violation of the specification. In this case the Publisher MUST consider a possible Subscription for this Subscriber as canceled. The Publisher SHOULD raise this error condition in a fashion that is adequate for the runtime environment (e.g. by throwing an exception, notifying a supervisor, logging, etc.)."

I think it's safe enough to change SHOULD to MUST in that sentence, since it means that you can't just ignore it, even though it sometimes means that all you can do is to log it, rethrow it etc. The most important thing here is that we need to let someone know, either by logging or by escalation.

"A failing onError invocation is a violation of the specification. In this case the Publisher MUST consider a possible Subscription for this Subscriber as canceled. The Publisher MUST raise this error condition in a fashion that is adequate for the runtime environment (e.g. by throwing an exception, notifying a supervisor, logging, etc.)."

[viktorklang]

Others? @reactive-streams/contributors

[smaldini]

👍

[viktorklang]

Time to finalize the votes, if you need more time, please respond here with how much time (reasonable) is needed to cast your vote. @reactive-streams/contributors

[tmontgomery]

👍

[benjchristensen]

"A failing onError invocation is a violation of the specification. In this case the Publisher MUST consider a possible Subscription for this Subscriber as canceled. The Publisher MUST raise this error condition in a fashion that is adequate for the runtime environment (e.g. by throwing an exception, notifying a supervisor, logging, etc.)."

I'm good with this.