handle specific errors cases in request.ts

[gudnuf]

Fixes: error handling

Description

There are a variety of errors that can occur when making a request to a mint.

• fetch fail -> instanceof NetworkError
• fetch succeeds, but status is neither 2xx nor 400 -> instanceof HttpResponseError
• fetch succeeds and status is 400 -> instanceof MintOperationError with specific Cashu Error code as defined in the nuts

...

Changes

• added NetworkError and MintOperationError classes
• catch fetch error and throw NetworkError
• If fetch succeeds but !response.ok (ie. http error), then throw MintOperationError if applicable otherwise HttpResponseError

PR Tasks

• Open PR
• run npm run test --> no failing unit tests
• run npm run format

[Egge21M]

Hey man, thanks for tasking this on! Your logic looks solid, the problems you are seeing in your tests stems from the pipeline transpiling to old days JavaScript. Classes were not a thing in ES5, so transpilers will build old-times prototype chains. However the Error object is special and overwrites these chains.

Fixing this is as easy as overwriting the prototype yourself:

export class NetworkError extends Error {
    status: number;
    constructor(message: string, status: number) {
        super(message);
        this.status = status;
        Object.setPrototypeOf(this, NetworkError.prototype);
    }
}

However we are going to move away from ES5 and the old pipeline very soon anyways. Depending on the timeline, this fix might not even be necessary

[Egge21M]

Regarding the structure of the classes:
I think having a separate sub-class for each error type is overkill. These classes do not really do anything, and the only differentiator is the error code and detail. Instead we could have a single MintOperationError that consumes the code and detail and that can be checked against quite easily like:

catch(e: unknown) {
  if (e instance of MintOperationError) {
    switch(e.code) {
      case x: 
        // do smth.
        break;
      case y:
        // do smth else
        break;
    }
  }
}

[gudnuf]

@Egge21M I made some changes. I kept the error messages for specific codes, but moved that into the MintOperationError constructor. I think this is useful in case the mint does not return a detail and then the client can have consistent error messages. And my tests pass now, thanks!!

Should I just remove the ApiError type? I don't really understand how it is being used. It looks like most of the responses have ApiError tagged on, but all the actual errors just thrown. Seems like we should get rid of ApiError and make the user catch and handle errors on their own.