Add ATError Object Generator

[drasticactions]

Inspired by @PassiveModding's PR for #111, this generates ATError objects based on the error object within the lexicon for a given endpoint. This is just hacked together to expose the idea of it (It could be expanded to use details if available, or be included in the constructor documentation as possible error types) but it should now make it possible to switch inside of the error flow for a given error, rather than inspecting it yourself.

[PassiveModding]

the aim of #111 was more to have a strongly typed reference such that I can respond with these from an api controller as a pds would.
an example:

    [HttpPost("com.atproto.server.createAccount")]
    public async Task<IActionResult> CreateAccount([FromBody] CreateAccountInput request)
    {
        try
        {
            var config = await _configRepository.GetConfigAsync();
            
            // directs user back to 'invite code' page in appview
            if (string.IsNullOrWhiteSpace(request.InviteCode))
            {
                // alternatively something akin to return ATErrorResponse(new InvalidInviteCodeError(StatusCode.BadRequest, "missing or invalid invite code"));
                return ATErrorResponse(Com.Atproto.Server.CreateAccount.Errors.InvalidInviteCode, "missing or invalid invite code");
            }
            ...


    public static IActionResult ATErrorResponse<T>(T enumError, string message) where T : Enum
    {
        return new ErrorResponseResult<T>(enumError, message, HttpStatusCode.BadRequest);
    }
    
    public class ErrorResponseResult<T> : ObjectResult where T : Enum
    {
        public ErrorResponseResult(T enumError, string message, HttpStatusCode statusCode) : base(new { error = enumError.ToString(), message = message })
        {
            StatusCode = (int)statusCode;
        }
    }

Personally my thoughts on the approach you have taken would be that you should still be able to construct an error type with the detail.Error field pre-populated

new InvalidInviteCodeError(statusCode, message)

namespace  FishyFlip.Lexicon
{
    /// <summary>
    /// FishyFlip ATError for InvalidInviteCode.
    /// </summary>
    public class InvalidInviteCodeError : FishyFlip.Models.ATError
    {
        public const string ErrorType = "InvalidInviteCode";
        
        public InvalidInviteCodeError(int statusCode, ErrorDetail detail) : base(statusCode, detail)
        {
        }
        
        public InvalidInviteCodeError(int statusCode, string message) : base(statusCode, new ErrorDetail(ErrorType, message))
        {
        }
    }
}

[PassiveModding]

I also think it would be nice to preserve the namespace and descriptions associated with the error responses but given that multiple routes can have the same error type it would cause issues in ATErrorGenerator.g.cs in it's current state since there would be multiple classes for a given errorType. Perhaps they could just be included as part of the summary xmldoc

[drasticactions]

The ATError object should already be returning the detail error message as part of ErrorDetail. The descriptions there shouldn't be necessary in that case, and adding them after the fact may be incorrect as to the reason for the error, so I don't feed comfortable doing that.

For having the errors themselves be encapsulated within the namespace (E.g having multiple of them) I'm not against it, but I'm trying to think how it would be useful in practice. Generating them would be straightforward, and to get the "correct" one would be to get the response URI, parse it for the Id and switch on that along with the error code to return the error class object (or the generic one if it doesn't exist).

Remember that the only difference in any of these objects is the value of ErrorDetail.Error. There is no other information, that I'm aware of, being returned that is otherwise missing. Checking the Lexicon, there are instances where there different areas are returning the same known error:

The object returned from the endpoint is the same between them all. You know the context of the error because you're getting it as part of a call to ATProto, so you know the endpoint you're calling. For that reason, I'm unsure if having this be two or three separate objects adds value...

That said, having it be fully namespace could add in discoverability. Since then if you wanted to know the known error types for a given endpoint, you could maybe type out FishyFlip.Lexicon.Com.Atproto.Repo.GetRecord.Errors to see the known errors and switch on them directly. It adds complexity, but makes it clear that these are expected errors and removes ambiguity.

I'll play around with it some more.

[PassiveModding]

InvalidSwap has different descriptions in com.atproto.repo.applyWrites and com.atproto.repo.createRecord and no description in com.atproto.repo.putRecord and com.atproto.repo.deleteRecord. Though that appears to be the only instance that mixes different description values

[PassiveModding]

And you're correct in the fact ATError.ErrorDetail would include it, if sourced from an error event but from the perspective of
"I want to construct and return these errors from an api", having a statically typed way to create the ErrorDetail class instance would be useful. I think continue with the current implementation but also generate instances ErrorDetail under the namespaces for each class.

vs

public class InvalidInviteCodeErrorDetail : FishyFlip.Models.ErrorDetail
{
    public InvalidInviteCodeErrorDetail(string message) : base("InvalidInviteCode", message)
    {
    }
}

[drasticactions]

The description values do have use for the Endpoint classes when stating the list of errors and what could be expected, so they could be added to the top constructor of the given main methods pointing to these exceptions.

I see your point for using ErrorDetail and that usecase but IMO I view these result objects as from the API rather than something you construct yourself and pass downstream to your consumers. In past versions I had sealed and internalized many of the component classes to try and enforce "This is from ATProtocol, don't extend it or make your own!" I really want to be clear that it's coming from you calling ATProtocol and it returning that object and/or error. I opened it up for this version as I saw some complaints that it prohibited mocks for tests, but I'm kinda operating on that thought process.

For example, in your use-case of the Invite Code. For a front-end client, you would be checking that with client-side validation first most likely to prevent that request from hitting your server. Your backend code could also validate it before calling ATProtocol, but you would probably want to handle that error yourself to make it clear that something went wrong in your application to get to that state, rather than return an object from this library. Or you could not validate that value in the backend, let it get processed by ATProtocol, which would return the error object, that you then pass back to your client application to handle.