Capturing gateway.sendAndWait exceptions

Imported from Google Groups
#1

Hi,

We are sending some commands in domain services and we like to capture the original exceptions thrown by the aggregates, but it seems the exception it lost and only the message remains.
The stack contains a “CommandExecutionException” with cause “AxonServerRemoteCommandHandlingException”.

Is there any way to determine which is the original exception thrown by the Aggregate?

Regards

#2

Hi! You can register interceptors like described here https://docs.axoniq.io/reference-guide/configuring-infrastructure-components/messaging-concepts/message-intercepting
you can wrap the chain.proceed() into try catch inside the message handler interceptor

#3

Thank you, the problem with the interceptors is that they execute in one side or another (command handler or dispatch). My problem is that I am able to know which exception has been thrown in the aggregate part at the gateway call. Interceptors only allow you to intercept, transform or block execution, but in the end the final exception and its causes remain the same, even if you wrap it into another one.

#4

So you want full exception in the gateway? Why would you need that?

#5

I do not need the full exception, even with a simple info (something more that text) could be enough. It is quite different from client perspective an invariant violation (e.g. you do not have enough available balance at this moment) than a technical problem or a bug. They could end up been different error codes in a REST API port.

#6

Oh, that makes sense.
I don’t know how to solve it for sure, I am interested too.
You could take a look at the sources and see how they do CommandExecutionException and override this behavior.
Also, you could see if it’s possible to use command metadata or unit of work context (don’t know if they go across JVMs)

#7

Hi all,

we have identified an issue with the current approach of reporting exceptions. This will be improved in 4.2 (PRs have already been merged). As of then, you can pass application-specific error objects from handler to dispatcher.

4.2 shouldn’t take long now… stay tuned!

Cheers,

Allard

#8

Thank you for your response. We upgrade to 4.2 as soon as we can