SendErrors is restrictive when considering that not all errors are ValidationErrors - FluentResults

Given that an endpoint needs to handle both requests and responses, the current implementation of SendErrors is heavily weighted towards problems on the request.

Full Disclosure, I am (trying) to use FluentResults to manage the errors that occur in the Application, Domain or Infrastructure layer. Calls to services within these layers return Result or Result<T>.

Throwing Exceptions is expensive, so I try to avoid throwing unnecessary exceptions such as when a record cannot be found in the database. Sure, I could return null, but in other circumstances, null could mean two or three things. Therefore, the Result class allows me to record each type of error that has occurred (usually one) lower in the stack, and pass them back up to the endpoint, which has some pre-determined logic to decide what to do with specific error types, or if it can’t give a more appropriate response (400, 403, 409 etc) then as a last resort it will return 500. Error messages and formats are standardised and even objects required by the errors are captured, for full information relating to the problem.

There are lots of things that can go wrong, are not exceptional, and other processes up the stack should know about before continuing.

On with the problem. SendErrors simply send the validation errors to the client. Which to me, means validation on the input. Errors that happened in my other layers, once the request was received, understood and validated are simply lost. It would be great if we could return some other (non-typed) response in the body. That doesn’t require me to throw an exception because something happened that I expected could happen.

Something like

    protected Task SendErrorsAsync(object response, int statusCode = 400, CancellationToken cancellation = default)
    {
        return HttpContext.Response.SendErrorsAsync(response, statusCode, Definition.SerializerContext, cancellation);
    }

Happy to share some specific code or a demo-repo if needed.

[kcadduk]

#366 Opened for your review

[dj-nitehawk]

such extension methods already exist: https://github.com/FastEndpoints/FastEndpoints/blob/main/Src/Library/Extensions/HttpResponseExtensions.cs

this is for sending the responses from within the interceptor right?

if so, we already have the ability to do a similar thing when shorcircuiting from within pre-processors: https://fast-endpoints.com/docs/pre-post-processors#short-circuiting-execution