Let me say first, there is no real problem that I’m experiencing. I just think there is an opportunity for some improvement when dealing with handler execution exceptions (either command or query).
As handler execution exceptions are essentially just wrappers intended to communicate error codes over the (grpc) wire, I believe there is no real benefit in creating a stack trace during handler execution exception construction.
Usually, stacktrace is created implicitly for all Java exceptions, unless disabled explicitly via a constructor parameter. In the source code of Java RuntimeException, for example, that boolean parameter is called
Unfortunately, the creation of stacktrace is a performance-intensive operation and would be best if it can be avoided. Stacktrace removal is not something that should be done commonly for exceptions in Java. However, in the case of handler execution exceptions, I believe it makes sense to offer
writableStackTrace as a constructor parameter as there is no real benefit in creating stacktrace for that particular scenario.
If relevant, a good explanation (and measurement) of various aspects of exception handling is available here: The Exceptional Performance of Lil' Exception . The article is rather old, and performance is probably improved over the last years, but I believe that the penalty of creating a stacktrace is still significant.
I hope it is clearer now what I’m rambling about