Repository navigation
Re-think Error Design #63
Description
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.
Reacted by Nathapon B. (O)
Activity
[admin-api] Reduced library error fields for now
kevinansfield commentedon Mar 22, 2019
One thing I've run into which trolled me hard for a while was
.responsebeing deleted from the error thrown bymakeRequest.I was throwing custom errors from our overridden
makeRequestfunction 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.requestto.resassuming 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 commentedon Jul 5, 2019
I think this is the best thing to do - and lines up with exposing primitives task
[admin-api] Reduced library error fields for now
[admin-api] Reduced library error fields for now
[admin-api] Reduced library error fields for now