[Feat]: Throwing REST errors with request object

[DarkMio]

Tell us what problem the feature would solve

Currently the thrown errors lack the context in which they are thrown and requires to parse the error message to figure out what went wrong. Especially with expected errors (404, for example), this causes friction.

Describe the solution you'd like

Axios has a tiny helper that smoothes over some edges: https://github.com/axios/axios/blob/6d4c421ee157d93b47f3f9082a7044b1da221461/lib/helpers/isAxiosError.js#L12

with that it's possible to write code such as:

try {
  return await axios.get<Result>(uri);
} catch (error) {
  // 404 is to be expected
  if(isAxiosError(error) && error.request.status == 404) {
    return;
  }
  throw error;
}

Describe alternatives you've considered

There are none beyond parsing the Error text.

Additional Info

The code here: https://github.com/discordeno/discordeno/blob/main/packages/rest/src/manager.ts#L477-L482

could be replace with:

export class DiscordRestErro extends Error {
  constructor(message?: string, request: Awaited<ReturnType<typeof fetch>>) { ... }
  isDiscordRestError: true
  ...
}
// ... 

if (!result.ok) {
  const err = (await result.json().catch(() => {})) as Record<string, any>
  // Legacy Handling to not break old code or when body is missing
  if (!err?.body) throw new Error(`Error: ${err.message ?? result.statusText}`)
  
  throw new DiscordRestError(JSON.stringify(err), result);
}

[Fleny113]

I think you are referring to the normal rest errors, that get throw at L358, L382 and L391, the problem is that even if you replace the current object rejection (that creates an error since they are unhandled) the stack trace would be lost and the only information is that comes from Discordeno. I'm not at the moment very much familiar with how the Promise constructor deals with stack traces as we do use it a few times

note: the code you put in the additional note is for the Rest proxy (when you send the rest request for discord to your server to then send it to discord, this is helpful when multiple application need to share the same resources that have a shared ratelimit)

[Fleny113]

With #3382 the error will get a stack trace but i didn't mark the pr to close this issue as I'm not convinced that adding the entire request object returned by fetch is a good idea

You still get the body (unless it is an error caused by too many retries for ratelimit / a fetch error, then there is no body but an error) and the status code from the request in the error.cause object