Exception handling mapping to REST http status codes / error message.

[christoph...@trifork.nl]

Hi there, 

Currently we use Axonhub/Axondb and need to deal with Exceptions from queryGateway and commandGateway. 

The pattern we use is to defined custom exceptions which will be thrown by QueryHandlers or CommandHandlers, 

resulting in CommandExecutionException or QueryExecutionException. 

Typically, the 'caller' is a REST controller, which will handle the exception by a spring boot exception adviser. 

Now, the original exception is lost, but the Exception message can be retrieved by unwrapping: 

1. CompletionException 

2. Command/QueryExecutionException

To deal with unwrapping and mapping to HTTP Status code, and also have a nicely formatted error message, 

we made a utility, which can be used in a CompletableFuture.exceptionally(...) method. It can either respond directly or throw an 

api exception which is handled by the Exception Adviser. 

The cool thing about this is , that it doesn't clutter the flow when chaining async calls. 

Some exceptions are from the framework, i.e. Aggregate Seq. number violations or Aggregate not found exceptions, so those will 

always need to be caught and mapped properly. (Like a 404 or something else... ) 

All things considers, this pattern works nicely for us, but we still doubt if this is the right pattern. 

My question to the community is, how do people deal with this very typical issue when using Axon. 

Alternatives: 

- Do not throw business exceptions, but put errors in Error objects returned by the CH or QH. 

- Throw business exceptions and handle them as we do. 

- Alternatives... ?? 

We would .be happy to share our utility, if anyone interested, please contact me privately). 

Rgds

Christophe Bouhier. 

[Steven van Beelen]

Hi Christophe,

That sounds like a nice utility, sweet stuff!

I've typically taken a similar approach to what your suggesting here, although I do believe yours is more advanced then what I've been doing.

So I'll definitely leech on this idea, assuming you don't mind. ;)

As such, I do not have any other alternatives in mind atm.

I do believe that returning Error objects isn't necessarily the nicest thing to do.

That's my 2 cents!

Cheers,

Steven

--
You received this message because you are subscribed to the Google Groups "Axon Framework Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to axonframewor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[christoph...@trifork.nl]

Hi Steven, 

Auch only noticed your response now, yeah so please re-use the idea. 

One follow-up question, I have is that we like how this works, however we get big stacktraces in our logs, 

when throwing exceptions on the handler side.  Is there anyway we can quiet this down, when we by purpose throw business exceptions? 

Thanks Christophe

On Friday, October 5, 2018 at 10:54:25 AM UTC+2, Steven van Beelen wrote:

Hi Christophe