Hi Oliver. Basically, you are on the right track with those Metadata, but that’s not needed in this case. Since you have different error types you can check the type of the error and return an appropriate status code to the client. You can check my video regarding that – I talked about it.

It is always a good practice to have an implementation of the Error class, or at least, this is the way that I am using the result pattern if I want to use it.

You can even have a base controller, and all your other controllers can inherit from that one. In that base controller, you can do the filtering of the error results and return a correct status code. This is very similar to an exception flow, and something I used in my API book named API Result flow.

The bottom line is that having special implementations of the Error class is always advisable and can help you identify the exact error result type you have and provide a correct response for your clients. You don’t need any extension packages for that.

‘Now, we can create our error classes by extending the Error class provided by the library’

Why would I do that ? What do I gain from that ? They essentially do the same thing, but just have different names. Couldn’t I just use the Fail that the library comes with ?

I could see a potential if I would make them more generic and add status codes as metadata, similar to this:

public class RecordNotFoundError : Error
{
public RecordNotFoundError(string message)
: base(message)
{
Metadata.Add(“HttpStatusCode”, 404);
}
}

public class ValidationError : Error
{
public ValidationError(string message)
: base(message)
{
Metadata.Add(“HttpStatusCode”, 400);
}
}

But to transform it to an Action Result I would need an extension package:
https://github.com/altmann/FluentResults/wiki/Returning-Result-Objects-from-ASP.NET-Core-Controller#add-transformation-logic-to-controller

But the documentation about that is unclear to me.