feat: Wrap AxiosErrors in custom error object

[joe-yeager]

Description and Context

I think our http functions could be considered a leaky abstraction because we are directly exposing AxiosErrors which requires the projects depending on these functions to write axios specific logic in their code base, such as checking e.response && e.response.status in catch blocks. What I am proposing is that we globally wrap all AxiosErrors in our own custom Error to keep the implementation details limited to this repository.

This would mean that error checking could be simplified from something like:

try {
   await someFunctionThatMakesAnHttpCall();
} catch (e) {
  if(isHubSpotHttpError(e). && e.status === 404) {
     console.log('Unable to find the thing you were looking for')
  }
}

So the resulting code is completely unaware that axios is being used under the hood.

Who to Notify

@brandenrodgers @camden11 @kemmerle

[camden11]

This is a really good idea - we should absolutely be giving consuming libraries everything they need to interface with the errors we throw here. Should definitely be very careful to make sure we don't lose any info contained in the errors along the way, but I don't really see a downside to doing this

[joe-yeager]

Should definitely be very careful to make sure we don't lose any info contained in the errors along the way

@camden11 💯

My understanding is that by creating the new error type and setting the error thrown by axios as cause we preserve all of the stack trace context. We can also still access the axios error fields in the event there is a piece of information we don't have available on the top level of the new error.

[kemmerle]

Besides the one tiny nit, this all looks great to me. Particularly like how you made the request fields top level in HubSpot errors. Chef's kiss👩‍🍳 💋

[brandenrodgers]

Just recording here that this will be a major version bump since it's a breaking change (totally fine, just wanted to add a comment for posterity)