Exception handling middleware

[yshchohaleu]

No description provided.

[rurku]

I'm against including this stolen exception handling configuration code into this library because

• If we just copy it like this then we need to maintain it
• we need to document it
• it does more than we actually need
• the current solution limits what the user can do - user can only return a different message and status code, but not a different response format or response headers

I suggest that we do it like this

• remove the stolen code❗️
• in WacWebApiExceptionHandlerOptions add a delegate that can be used in Startup to add extra exception handling logic. It would be used for exceptions not derived from WebApiException.
  The delegate would look like this Func<ExceptionHandlingContext> and ExceptionHandlingContext would contain

public HttpContext HttpContext { get; set;}
public Exception Exception { get; set;}
// If Handled is set to true then the middleware will not rethrow the exception.
public bool Handled { get; set;}

[rurku]

all exceptions derived from

But it's not true anyway, because it also handles unhandled exceptions.

[HerbertBodner]

the parameter logger is not used anywhere

[HerbertBodner]

typo in method name

[HerbertBodner]

I think it would be nice to put this property in the WacWebApiExceptionHandlerOptions class, so the user can change the text, if he wants to. (public string UnhandledExceptionMessage = "Internal server error";)

[HerbertBodner]

In general, I tend to agree with Jacek, because the whole code is rather complicated to understand and therefore hard to maintain. And also I don´t really see the use case of some options. In particular, I don´t see the value of having HandlingInput class.

On the other hand, the way Jacek suggests is on my opinion too simple.
I´d go for some middle-ground solution, where you keep the On<TException>(Func<TException, TResult> handler) method (maybe with the condition parameter if it is simple to do).

[HerbertBodner]

I noticed that this method seems to return always false, because handlerExceptionType is always of type Exception.
I guess, that it should return true, if you specify a WebApiException handler in the startup as follows:

                    .On<WebApiException>(e => WacHandling.Handled(new WebApiExceptionDto
                    {
                        Message = "test my own handling",
                        HttpStatusCode = (HttpStatusCode)0,
                        ErrorReference = Guid.NewGuid().ToString()
                    }))

[HerbertBodner]

I created my own class MyExceptionDto, which does not derive from WebApiExceptionDto

public class MyExceptionDto {
        public string MyProperty { get; set; }
    }

and added it In the startup of the example project like this:

.On<BadRequestException>(e => WacHandling.Handled(new MyExceptionDto
                {
                    MyProperty = "MyTest",
                }))

This resulted in a NullReferenceException on this line. Somehow the exceptionDto gets lost somewhere and is null here.

[HerbertBodner]

I was wondering where you would implement Logging of exceptions.
Is FinalizeWith the method, where you would do that?
If not, what is an example, where this method would be used?