The exception is not considered as a result of a
@SagaEventHandler annotated method. This is different for command handling, as there is a Command Response. The response can be successful (a
void handler) or exceptional (from the exception thrown in the command handler.
@Laura_Winnen, the retry behaviour you are speaking of is likely maintained inside the
@SagaEventHandler annotated method, correct? That most mean you are invoking the
CommandGateway in a try-catch block. Thus, it is your implementation which already catches the exception. Henceforth, there wouldn’t even be anything to expect in such a scenario.
The solution given by @lfgcampos signals the approach of how to define what the
CommandBus will do when you dispatch a command. That means that it allows you to enter your catch-block, thus validate the type of (message) operation you’d perform in the event handler.
If my assumptions are incorrect, and you truly have a situation where the exception does need to bubble up out of the Saga, then you’d have to take a look at the
ListenerInvocationErrorHandler. Exceptions are thrown from within event handlers (like a
@SagaEventHandler annotated method) are caught in a so-called
EventHandlerInvoker. This invoker will call the configured
ListenerInvocationErrorHandler for every exception being caught by the invoker.
As it stands, you can configure the
ListenerInvocationErrorHandler for the
SagaTestFixture if you want. It defaults to the
LoggingErrorHandler both you @Laura_Winnen and you @dmarcelino have noted. If you want the exception to propagate further, you can change it to a
PropagatingErrorHandler. Or, you can define a custom
ListenerInvocationErrorHandler, which can validate the exception for your if you will.
Lastly, if you feel there’s benefit in an
expectException method on the
SagaTestFixture, it would be great if either of you could create an issue for it here.