Command Exception Handling

Hi everyone,

I am currently using axon & axon server v4.1, in a spring boot application, and I am having difficulty getting a custom error (checked not runtime) back from the command handler that throws it.

I have tried using the default Command Gateway and creating my own custom Command Gateway as the documentation suggests
https://docs.axoniq.io/reference-guide/configuring-infrastructure-components/command-processing/command-dispatching#creating-a-custom-command-gateway

It reads that any declared exceptions on the method will be thrown, while any undeclared will be wrapped in a CommandExecutionException, but I can only get the later.

This is the test Command Gateway and the initialization I have setup.

`
public interface TestCommandGateway {

void sendCommandAndWait(Object command)
throws TestException, InterruptedException;

CompletableFuture send(Object command) throws TestException;
}
`



@Bean
public TestCommandGateway testCommandGateway(CommandBus commandBus) {
 CommandGatewayFactory build = CommandGatewayFactory.builder().commandBus(commandBus).build();
 return build.createGateway(TestCommandGateway.class);
}

At this point I am trying to get my exception back, since it contains more information about what went wrong, as a Map<String, Object> that I want to have in the response body.

From the CommandExecutionException/AxonServerRemoteCommandHandlingException objects only a description is available , which is not what I would like to return to the user.

As a note, I have read at some older post, that the exception thrown on the axon server is not transferred to the spring boot application, but I am not really sure if that is true.

Please let me know if I am doing something wrong, or if there is another way around this that I am not aware of.

Thank you in advance,

George Ginis

Hi George,

there is indeed an issue with error reporting when using AxonServer at the moment. It isn’t actually related to AxonServer itself, but rather how Axon reports exceptions. As exceptions are sent “over the wire”, it translates exceptions using an error code and a description of the “causes”. Unfortunately, there was no way until now to add anything else, which the dispatching node could use to make decisions.
In 4.2, we will be adding the possibility to send an application-specific details object along with your exception. The dispatching node will then be able to read the details object and take decisions based on it. This object will be accessible through the CommandExecutionException (or QueryExecutionException when the exception is returned as result of a query).

We’re currently targeting mid-May for the 4.2 release.

Kind regards,