Interface ErrorHandler

All Known Implementing Classes:

ForeverRetryingErrorHandler, LoggingErrorHandler, RetryingErrorHandler, SilentErrorHandler, ThrowingErrorHandler

Functional Interface:

This is a functional interface and can therefore be used as the assignment target for a lambda expression or method reference.

@FunctionalInterface
public interface ErrorHandler

Handles failures during tracked message processing, optionally retrying the failed operation.

Start with LoggingErrorHandler, the consumer default: it logs failures and lets processing continue without retrying. Select a different policy only when the consumer's effect and recovery requirements call for it. Continuing can advance the position past a failed effect; it does not repair that effect.

Warning: ThrowingErrorHandler does not retry. It can stop the affected tracker until explicit restart, typically application restart or redeployment after repair. Even a functional rejection can stop it. Other trackers or application instances may continue; this is not a global consumer pause.

Built-in consumer error policies

Implementation	Behavior	Choose when
LoggingErrorHandler	Log and continue; no retry	Recommended starting point; continued failures are observable and recoverable if needed
RetryingErrorHandler	Retry eligible failures; default: five retries, then continue	Bounded recovery from transient failures with repeatable effects
ForeverRetryingErrorHandler	No retry-count limit for eligible failures	Recoverable failures must hold up progress, with idempotency, lag alerts and operator recovery
ThrowingErrorHandler	Rethrow immediately; stop the affected tracker	A deliberate operator-controlled stop, with a repair and restart procedure
SilentErrorHandler	Continue without retry; configurable or no logging	Best-effort work with separate observability

The supplied retry operation can cover a handler or a batch, depending on where the failure occurred. Completed effects are not rolled back and may repeat. Unlimited retries are not an exactly-once or delivery guarantee; see ForeverRetryingErrorHandler for filtering and interruption boundaries.

Method Summary

Modifier and Type	Method	Description
default void	handleError(Throwable error, String errorMessage, Runnable retryFunction)	Handles an error encountered during message processing and provides an option to retry the operation.
Object	handleError(Throwable error, String errorMessage, Callable<?> retryFunction)	Handles an error encountered during message processing and provides an option to retry the operation.

Method Details

handleError

Object handleError(Throwable error,
 String errorMessage,
 Callable<?> retryFunction)

Handles an error encountered during message processing and provides an option to retry the operation.

Parameters:

error - the Throwable instance representing the error that occurred

errorMessage - a descriptive message providing context about the error

retryFunction - a Callable representing the operation to retry in case of failure

Returns:

an Object which represents the result of the error handling or retry operation. In case an exception is thrown, the affected tracker can stop until explicitly restarted; throwing does not schedule a retry. If an error is returned rather than thrown, tracking may continue and the error may be published as a Result message. Any other return value may also be published as a Result message.

handleError

default void handleError(Throwable error,
 String errorMessage,
 Runnable retryFunction)

Handles an error encountered during message processing and provides an option to retry the operation. Invoked when the return value of the error handler (even if the return value is an exception) is not relevant.

Parameters:

error - the Throwable instance representing the error that occurred

errorMessage - a descriptive message providing context about the error

retryFunction - a Callable representing the operation to retry in case of failure