Reactor Core 3.6.0 · reactor.core.publisher.InternalEmptySink

Modifier and Type	Method and Description
public default void	emitEmpty(Sinks.EmitFailureHandler the failure handler that allows retrying failed `EmitResult`. failureHandler) Implements reactor.core.publisher.Sinks.Empty.emitEmpty. A simplified attempt at completing via the `tryEmitEmpty()` API, generating an `onComplete` signal.
public default void	emitError(Throwable the exception to signal, not null error, Sinks.EmitFailureHandler the failure handler that allows retrying failed `EmitResult`. failureHandler) Implements reactor.core.publisher.Sinks.Empty.emitError. A simplified attempt at failing the sequence via the `tryEmitError(Throwable)` API, generating an `onError` signal.

Method Detail

emitEmpty back to summary

emitEmpty	back to summary
public default void emitEmpty(Sinks.EmitFailureHandler failureHandler) Implements reactor.core.publisher.Sinks.Empty.emitEmpty. Doc from reactor.core.publisher.Sinks.Empty.emitEmpty. A simplified attempt at completing via the `tryEmitEmpty()` API, generating an `onComplete` signal. If the result of the attempt is not a `success`, implementations SHOULD retry the `tryEmitEmpty()` call IF the provided `EmitFailureHandler` returns `true`. Otherwise, failures are dealt with in a predefined way that might depend on the actual sink implementation (see below for the vanilla reactor-core behavior). Generally, `tryEmitEmpty()` is preferable since it allows a custom handling of error cases, although this implies checking the returned `EmitResult` and correctly acting on it. This API is intended as a good default for convenience. When the `EmitResult` is not a success, vanilla reactor-core operators have the following behavior: `EmitResult#FAIL_OVERFLOW`: irrelevant as onComplete is not driven by backpressure. `EmitResult#FAIL_ZERO_SUBSCRIBER`: the completion can be ignored since nobody is listening. Note that most vanilla reactor sinks never trigger this result for onComplete, replaying the terminal signal to later subscribers instead (to the exception of `UnicastSpec#onBackpressureError()`). `EmitResult#FAIL_CANCELLED`: the completion can be ignored since nobody is interested. `EmitResult#FAIL_TERMINATED`: the extra completion is basically ignored since there was a previous termination signal, but there is nothing interesting to log. `EmitResult#FAIL_NON_SERIALIZED`: throw an `EmissionException` mentioning RS spec rule 1.3. Note that `Sinks#unsafe()` never trigger this result. It would be possible for an `EmitFailureHandler` to busy-loop and optimistically wait for the contention to disappear to avoid this case in safe sinks... Might throw an unchecked exception as a last resort (eg. in case of a fatal error downstream which cannot be propagated to any asynchronous handler, a bubbling exception, a `EmitResult#FAIL_NON_SERIALIZED` as described above, ...). Parameters failureHandler:Sinks.EmitFailureHandler the failure handler that allows retrying failed `EmitResult`. Annotations @Override

public default void emitEmpty(Sinks.EmitFailureHandler failureHandler)

Implements reactor.core.publisher.Sinks.Empty.emitEmpty.

Doc from reactor.core.publisher.Sinks.Empty.emitEmpty.

A simplified attempt at completing via the tryEmitEmpty() API, generating an onComplete signal. If the result of the attempt is not a success, implementations SHOULD retry the tryEmitEmpty() call IF the provided EmitFailureHandler returns true. Otherwise, failures are dealt with in a predefined way that might depend on the actual sink implementation (see below for the vanilla reactor-core behavior).

Generally, tryEmitEmpty() is preferable since it allows a custom handling of error cases, although this implies checking the returned EmitResult and correctly acting on it. This API is intended as a good default for convenience.

When the EmitResult is not a success, vanilla reactor-core operators have the following behavior:

EmitResult#FAIL_OVERFLOW: irrelevant as onComplete is not driven by backpressure.
EmitResult#FAIL_ZERO_SUBSCRIBER: the completion can be ignored since nobody is listening. Note that most vanilla reactor sinks never trigger this result for onComplete, replaying the terminal signal to later subscribers instead (to the exception of UnicastSpec#onBackpressureError()).
EmitResult#FAIL_CANCELLED: the completion can be ignored since nobody is interested.
EmitResult#FAIL_TERMINATED: the extra completion is basically ignored since there was a previous termination signal, but there is nothing interesting to log.
EmitResult#FAIL_NON_SERIALIZED: throw an EmissionException mentioning RS spec rule 1.3. Note that Sinks#unsafe() never trigger this result. It would be possible for an EmitFailureHandler to busy-loop and optimistically wait for the contention to disappear to avoid this case in safe sinks...

Might throw an unchecked exception as a last resort (eg. in case of a fatal error downstream which cannot be propagated to any asynchronous handler, a bubbling exception, a EmitResult#FAIL_NON_SERIALIZED as described above, ...).

Parameters

failureHandler:Sinks.EmitFailureHandler: the failure handler that allows retrying failed EmitResult.

Annotations

@Override

emitError back to summary

emitError	back to summary
public default void emitError(Throwable error, Sinks.EmitFailureHandler failureHandler) Implements reactor.core.publisher.Sinks.Empty.emitError. Doc from reactor.core.publisher.Sinks.Empty.emitError. A simplified attempt at failing the sequence via the `tryEmitError(Throwable)` API, generating an `onError` signal. If the result of the attempt is not a `success`, implementations SHOULD retry the `tryEmitError(Throwable)` call IF the provided `EmitFailureHandler` returns `true`. Otherwise, failures are dealt with in a predefined way that might depend on the actual sink implementation (see below for the vanilla reactor-core behavior). Generally, `tryEmitError(Throwable)` is preferable since it allows a custom handling of error cases, although this implies checking the returned `EmitResult` and correctly acting on it. This API is intended as a good default for convenience. When the `EmitResult` is not a success, vanilla reactor-core operators have the following behavior: `EmitResult#FAIL_OVERFLOW`: irrelevant as onError is not driven by backpressure. `EmitResult#FAIL_ZERO_SUBSCRIBER`: the error is ignored since nobody is listening. Note that most vanilla reactor sinks never trigger this result for onError, replaying the terminal signal to later subscribers instead (to the exception of `UnicastSpec#onBackpressureError()`). `EmitResult#FAIL_CANCELLED`: the error can be ignored since nobody is interested. `EmitResult#FAIL_TERMINATED`: the error unexpectedly follows another terminal signal, so it is dropped via `Operators#onErrorDropped(Throwable, Context)`. `EmitResult#FAIL_NON_SERIALIZED`: throw an `EmissionException` mentioning RS spec rule 1.3. Note that `Sinks#unsafe()` never trigger this result. It would be possible for an `EmitFailureHandler` to busy-loop and optimistically wait for the contention to disappear to avoid this case in safe sinks... Might throw an unchecked exception as a last resort (eg. in case of a fatal error downstream which cannot be propagated to any asynchronous handler, a bubbling exception, a `EmitResult#FAIL_NON_SERIALIZED` as described above, ...). Parameters error:Throwable the exception to signal, not null failureHandler:Sinks.EmitFailureHandler the failure handler that allows retrying failed `EmitResult`. Annotations @Override

public default void emitError(Throwable error, Sinks.EmitFailureHandler failureHandler)

Implements reactor.core.publisher.Sinks.Empty.emitError.

Doc from reactor.core.publisher.Sinks.Empty.emitError.

A simplified attempt at failing the sequence via the tryEmitError(Throwable) API, generating an onError signal. If the result of the attempt is not a success, implementations SHOULD retry the tryEmitError(Throwable) call IF the provided EmitFailureHandler returns true. Otherwise, failures are dealt with in a predefined way that might depend on the actual sink implementation (see below for the vanilla reactor-core behavior).

Generally, tryEmitError(Throwable) is preferable since it allows a custom handling of error cases, although this implies checking the returned EmitResult and correctly acting on it. This API is intended as a good default for convenience.

When the EmitResult is not a success, vanilla reactor-core operators have the following behavior:

EmitResult#FAIL_OVERFLOW: irrelevant as onError is not driven by backpressure.
EmitResult#FAIL_ZERO_SUBSCRIBER: the error is ignored since nobody is listening. Note that most vanilla reactor sinks never trigger this result for onError, replaying the terminal signal to later subscribers instead (to the exception of UnicastSpec#onBackpressureError()).
EmitResult#FAIL_CANCELLED: the error can be ignored since nobody is interested.
EmitResult#FAIL_TERMINATED: the error unexpectedly follows another terminal signal, so it is dropped via Operators#onErrorDropped(Throwable, Context).
EmitResult#FAIL_NON_SERIALIZED: throw an EmissionException mentioning RS spec rule 1.3. Note that Sinks#unsafe() never trigger this result. It would be possible for an EmitFailureHandler to busy-loop and optimistically wait for the contention to disappear to avoid this case in safe sinks...

Parameters

error:Throwable: the exception to signal, not null
failureHandler:Sinks.EmitFailureHandler: the failure handler that allows retrying failed EmitResult.

Annotations

@Override

pack-priv Interface InternalEmptySink<T>

Method Summary

Method Detail