Ah I remember seeing this from when I converted off 5.0.
I chose not to use it because I do some other exception voodoo such as sending responses back to the originator should exceptions or business exceptions happen and ErrorContext doesn’t have extensions for sending messages. So therefore I would be adding a bunch of code just to change a “return” to a “throw” so recoverability gets triggered.
(which btw adding the ability to send replies from recoverability would be pretty neat)
Not publishing “Published” messages would be an additional bonus - but to take advantage of the feature I would have to rewrite a portion of the Entity related code in my library to call Bus.Publish when applying these types of events that are published out NSB. All just so the exchange name is not “_impl” - not sure if the benefits outweigh the additional complexity as the majority of uses of Apply<> will create an event to be saved to eventstore not NSB - so I’ll need to queue events until the unit of work finishes in any case.
in general yes, but this can depend on the place in the pipeline where you catch and swallow the exception. I’d recommend to catch business exceptions you want to ignore directly in the handler where it’s visible and obvious to a reader that the exceptions have no impact on the message processing.
A solid point - but BusinessExceptions are known pretty generally to not be message errors - just validation errors. When an entity throws a BusinessException the handler is not catching it explicitly but there would be virtually no benefit to swallowing it there because I still have to reply to the originator that the command failed validation. It would be more clear to someone reading the code but would lead to A LOT of duplicated code to
being that explicit would just be overkill since everyone knows what a BusinessException means AND I’d still have to send a reply. If I were throwing some other exception I’d be right there with ya