Re-think Error Design

[kirrg001]

Axios library returns err.response, err.request and err.config, which are very fat and make stdout impossible to read. Need to figure out if we have to return some of these values to the user or not. And if so, we have to define the output + design.

The v2 JSON API returns this on error:

errors: [{id: ..., help: ...., code: ....,  details:...}]

SDK deserializes these fields into:

{ ValidationError: Validation error, cannot save post.
    at makeRequest.catch (ghost/ghost-sdk/packages/admin-api/lib/index.js:290:33)
    at process._tickCallback (internal/process/next_tick.js:68:7)
  name: 'ValidationError',
  context: 'Validation failed for \'posts[0]\'',
  type: 'ValidationError',
  details:
   [ { keyword: 'required',
       dataPath: '.posts[0]',
       schemaPath: '#/properties/posts/items/required',
       params: [Object],
       message: 'should have required property \'title\'' } ],
  help: null,
  code: null,
  id: '2f5ebe00-3917-11e9-8a93-53537def9b36' }

This is cool. But if you get a library error, the error looks like:

{ Error: connect ECONNREFUSED 127.0.0.1:2368
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1104:14)
  errno: 'ECONNREFUSED',
  code: 'ECONNREFUSED',
  syscall: 'connect',
  address: '127.0.0.1',
  port: 2368 }

Error is different. This is hard to document & hard to work with.
Need to figure out what todo.

[kevinansfield]

One thing I've run into which trolled me hard for a while was .response being deleted from the error thrown by makeRequest.

I was throwing custom errors from our overridden makeRequest function and was attaching the request as I needed conditional logic based on the response status code. Spent ages trying to work out why my response object wasn't available on the error without thinking to check that this package could be modifying errors rather than simply passing them through (I didn't actually get that far, I ended up renaming .request to .res assuming it was some weird zapier-cli quirk 🙈).

Does it make more sense to pass errors through as-is in this library and leave it up to the consumer's error handling/logging to do what it needs to do?

[allouis]

Does it make more sense to pass errors through as-is in this library and leave it up to the consumer's error handling/logging to do what it needs to do?

I think this is the best thing to do - and lines up with exposing primitives task