ProblemDetails, custom action before Catch exception

[ShaneGooseman]

Is there a way I can take pre-catch action for the exception?
I need to take an action in case of an exception

[khellang]

Hi @ShaneGooseman! 👋

Is there a way I can take pre-catch action for the exception?
I need to take an action in case of an exception

I think you need to be a bit more specific here. There's no way to do anything to exceptions pre-catch in C# 😉 I'm assuming you're referring to the period between the exception is caught and the response is sent to the client? What specifically are you looking to do?

There are a couple of callbacks you can configure, like ShouldLogUnhandledException, but without knowing what you're trying to accomplish, it's hard to tell whether you could use that API to do it 😅

[ShaneGooseman]

I understand that your midleware catches the exception and formats it following the Problem Details standard.
I need to get information from that exception just before you format it and take an action. Specifically, I want to register the error in Sentry.

[khellang]

I need to get information from that exception just before you format it and take an action. Specifically, I want to register the error in Sentry.

In that case, you have three options:

1. Hook up the ShouldLogUnhandledException callback, which is called for every unhandled exception. You can use that to log the exception, then just return the default. The downside of this approach is that it doesn't support async/await.
2. Write your own middleware to catch, log and rethrow exceptions and hook it up after the ProblemDetails middleware.
3. Write your own middleware to catch and log exceptions, hook it up before the ProblemDetails middleware and configure the ProblemDetails middleware to rethrow certain types of exceptions.

I would probably go for 1. if you don't need async/await and 2. otherwise.

[khellang]

Or, if you don't want to write your own logging middleware, maybe you can use Sentry.AspNetCore? 🤔

[ShaneGooseman]

The first thing I did was step 2, but it happens that problemdetails catches the exception as an exception happened in my midleware

[khellang]

If ProblemDetails catches the exception, it's because you've added it too late to the pipeline:

If this is your setup (this is the default when you call UseSentry on the host builder):

app.UseSentry(); // Or your custom middleware

app.UseProblemDetails();

app.UseEndpoints(/* endpoint config in here /*); // Exception happens here...

You need to call

services.AddProblemDetails(options => options.Rethrow<Exception>());

In order for the ProblemDetails middleware to rethrow the exception to be logged by Sentry.

---

If this is your setup:

app.UseProblemDetails();

app.UseSentry(); // Or your custom middleware

app.UseEndpoints(/* endpoint config in here /*); // Exception happens here...

The exception should be logged by Sentry before reaching the ProblemDetails middleware and everything should Just Work™

[ShaneGooseman]

Thank you very much!

But the order of midleare is
app.UseMiddleware(typeof(MyCustomMidleWare));
app.UseProblemDetails();

[khellang]

Right, so if you swap the order (and make sure your middleware re-throws the exception), everything should work 😄

[CleytonGoncalves]

@khellang I'm trying to use this with Serilog's RequestLoggingMiddleware.

On Startup, ProblemDetails must come after RequestLoggingMiddleware, because otherwise whenever MapToStatusCode is used, the wrong status code would be logged (i.e. status code would be assigned after logging), right?

ProblemDetails catches the exceptions that would make the logging middleware record its details (https://github.com/serilog/serilog-aspnetcore/blob/dev/src/Serilog.AspNetCore/AspNetCore/RequestLoggingMiddleware.cs#L65). The problem is that when I Rethrow<Exception>(), the response becomes empty (and I couldn't figure out why).

For now I'm working around it by injecting the logger context inside ShouldLogUnhandledException and adding the exception as a regular property, but it isn't the same as when logging it AS an exception.

options.ShouldLogUnhandledException = (httpCtx, err, details) =>
{
    _requestLogCtx.Set("Exception", err);
    return false;
};

Is there any better way? Thank you!

[khellang]

Is there any better way?

I don't think so. As I explained in #94, the solution is to re-throw. I would really like to get to the bottom of why your responses turn out empty. Maybe you can turn on debug logging and file a new issue with some more information? 🤔