Prepare work on 3.2.0, integrate error mode (for MILESTONE 1) #1021
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
this second commit makes resume() cancel the upstream and add the original error as suppressed in case of a consumer failure. it also adds a conditionalResume() that only applies to failures matching the BiPredicate, falling back to STOP for other failures. Once again, if the predicate or consumer fail, the original error is added to the exception as suppressed and the later is passed to STOP. Added unit tests of both customizable strategies.
The API takes BiConsumer<Throwable, T>, although these are brutally casted down to Object in the underlying implementations
as doOn* operators don't change the sequence, it makes no sense calling the strategy with a value. Having the predicate only deal with the Throwable and the BiConsumers split into valueConsumer vs errorConsumer allows for more flexibility, taking the peek use case into account with the same strategy method.
- strategy now checks if `canResume` and can then `process` - "stop" fallback now entirely done in Operators#onNextFailure, which is a util for the 80% use case (dealing with failure in onNext) - added Operators method to just get the strategy - FluxPeek uses that to specifically deal with some callback errors, as these don't modify the source sequence when recovered from.
- strategy processing can return a Throwable - default strategies catch consumer errors and return them, suppressing the original error - if strategy returns a Throwable, the Operators.onNextFailure util will cancel the subscription - evaluation of throwIfFatal is made as late as possible in order for strategies to be able to recover from a fatal exception if strategy has a predicate that explicitly matches that exception type (not a joker null predicate) - resume strategy with value consumer passes `null` along to the consumer which should be prepared to receive such a value. unused for now. In order to help with tests, the `AssertSubscriber` can now be built with a customized Context.
see also discussion in PR #957
simonbasle
added a commit
that referenced
this pull request
Feb 16, 2018
See #629 and #840 This commit adds an error strategy concept to some of the operators that let `Flux` and `Mono` recover from an error mid-stream: the `continue` strategy. Such errors are dropped into a special hook, and the sequence can continue with the next value from the upstream. Operators that support this mode have a special tag in their javadoc. These include `map`, `filter`, `flatMap`, `handle`, `doOnNext`. The error mode is activated using `Context`, so it follows the same propagation semantics. The API is on `Flux`: - `errorStrategyContinue(...)` will activate the continue strategy for that particular `Flux`, upstream of it. - `errorStrategyStop()` let you go back to the default RS behavior, eg. in case you don't want the continue strategy to apply within a `flatMap`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The plan is to use the
3.2.0-preparebranch to work on 3.2-specific features while we are still officially on the 3.1.x line.