Mediatr: Add exception handler pipeline behavior

[daniel-white]

I think there's a place for an IRequestExceptionHandler in the vein of IPreRequestProcessor and IPostRequestProcessor.

It would have a single method to implement

Task Handle(
    TRequest request,
    Exception exception,
    ExceptionHandlerState<TResponse> state,
    CancellationToken cancellationToken
)

The state object would work like this

    public class RequestExceptionHandlerState<TResponse>
    {
        public TResponse Response { get; private set; }

        public bool Handled { get; private set; }

        public void SetHandled(TResponse response = default)
        {
            Handled = true;
            Response = response;
        }
    }

Here's my use case for it. I have certain requests that update a database using Entity Framework Core. One project has the implementation in a request handler with no specific DB provider dependency/reference. I have another layer that implements the specific DB provider and naming. The exception is thrown as a type from the DB provider library. With a IRequestExceptionHandler, I can intercept the exception, do some DB specific logic and throw a domain specific exception.

Thoughts?

P.S.

I thought if this is in the main library, I could do some work to resolve IRequestExceptionHandlers based on the type of the exception similar to how catch blocks work, but I would need the ServiceFactory.

[remcoros]

Interesting concept. I think this can be build using a behavior (pipeline) on top of mediatr already. You can inject ServiceFactory into the constructor of the behavior and use that to resolve your own types.

[daniel-white]

@remcoros yea, that's how i have it implemented in my codebase. It's not a critical feature to have the inheritance for exceptions with pattern matching in the language, just a "nice to have"

[remcoros]

The behavior is a service locator itself (it locates exception handlers) so depending on the container there (or in this case, the ServiceFactory delegate) is perfectly fine.

Up to Jimmy if he wants this in the core package. You can always send a PR :)

[daniel-white]

@jbogard is this something that the core package could use/own? i dont want to waste any time if its just going to get shot down at that stage.

[jbogard]

The whole point of the pre and post processor was to introduce a more fine
grained pipeline than just the behaviors. Let’s see what you come up with!

On Tue, Nov 27, 2018 at 1:53 PM Daniel A. White [e-mail]
wrote:

@jbogard https://github.com/jbogard is this something that the core
package could use/own? i dont want to waste any time if its just going to
get shot down at that stage.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/jbogard/MediatR/issues/337#issuecomment-442194140,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGYMkrVTHbtUeHGmU1Fncfo9Zd8q64Wks5uzZgqgaJpZM4YyOXr
.

[daniel-white]

That makes sense and exceptions to me would fall under that umbrella. I should have at least a prototype soon.

[developermj]

Is there any traction on getting this exception handling code released? I'd like to make a handler that sends the exception to application insights.

[jbogard]

Yeah, I was waiting to see if there were any more breaking changes...

On Sat, Sep 14, 2019 at 1:51 PM developermj [e-mail]
wrote:

Is there any traction on getting this exception handling code released?
I'd like to make a handler that sends the exception to application insights.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jbogard/MediatR/issues/337?email_source=notifications&email_token=AAAZQMVUV3BP4PZV6O5XM7TQJUXCDA5CNFSM4GGI4XV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6XB3LY#issuecomment-531504559,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAZQMRGTFDCECY5RE7D4JLQJUXCDANCNFSM4GGI4XVQ
.

[jbogard]

Fixed by #339