feat(service): throw service error with context

[ShookLyngs]

Changes

• Add context in the error object of the service lib
• Add error handling recipe in service lib readme

Related issues

• Resolves Inject context into errors of rgbpp-sdk/service #95

Details

You can now find context in the BtcAssetsApiError if the error was thrown from a request:

try { 
  ... 
} catch (e) {
  if (e instanceof BtcAssetsApiError) {
    console.log(e.context?.request);
    console.log(e.context?.response);
  }
}

This is the type of e.context:

interface BtcAssetsApiContext {
  request: {
    url: string;
    body?: Record<string, any>;
    params?: Record<string, any>;
  };
  response: {
    status: number;
    data?: Record<string, any> | string;
  };
}

[duanyytop]

Is val => !!val more simple and clear?

[ahonn]

I think val !== undefined is better, if val is 0, it will be filtered out here

[duanyytop]

Yes. The type of val is unknown

[ahonn]

We should avoid using void 0, it is the same as undefined, but not as easy to understand.

Some libraries/packages use void 0 because undefined can be shadowed by local variables, and void 0 is shorter and can save a few bytes. You may see underscore or lodash used this way, but it doesn't mean we need it.
For modern JavaScript/TypeScript, this is a problem that does not require concern. Local variable shadowing cannot occur in TypeScript, and bundle size should be left to webpack/esbuild or other tools, rather than written as void 0

[duanyytop]

I agree that undefined is better than void 0

[ShookLyngs]

It's kinda a coding style habit for me, I use it because it's easy to type.
I'll replace all void 0 to undefined in another pull request.