conductor-node 8.6.4 → 8.6.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +13 -9
- package/dist/package.json +1 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -158,16 +158,18 @@ const accountAddInput: QbdTypes.AccountAdd = {
|
|
|
158
158
|
|
|
159
159
|
## Error Handling
|
|
160
160
|
|
|
161
|
+
### `ConductorError`
|
|
162
|
+
|
|
161
163
|
Any and every error thrown by the Conductor API will be an instance of `ConductorError` or one of its subclasses, which all have the following properties:
|
|
162
164
|
|
|
163
|
-
| Property | Type
|
|
164
|
-
| ----------------- |
|
|
165
|
-
| `type` | `string`
|
|
166
|
-
| `code` | `string`
|
|
167
|
-
| `message` | `string`
|
|
168
|
-
| `endUserMessage` | `string`
|
|
169
|
-
| `integrationCode` | `string` | The unique error code supplied by the third-party integration for errors that come from the integration (i.e., instances of `ConductorIntegrationError`). This is useful for adding special handling for specific errors from the third-party integration.<br><br>E.g., QuickBooks Desktop might return an error with `integrationCode` for something specific to its accounting logic. The integration's corresponding message for this code would be in `error.message`.<br><br>The third-party integration's error codes are not standardized, so you should not rely on this code to be the same across integrations. |
|
|
170
|
-
| `httpStatusCode` | `number` | The HTTP status code of the response that included the error. You probably won't need this. |
|
|
165
|
+
| Property | Type | Description |
|
|
166
|
+
| ----------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
167
|
+
| `type` | `string` | The error type, which categorizes the error. See [Error Types](#error-types) below.<br><br>This value is the same as the subclass name. E.g., `"ConductorIntegrationError"` or `"ConductorInvalidRequestError"`. |
|
|
168
|
+
| `code` | `string` | The unique error code from Conductor, which is useful for adding special handling for specific errors. E.g., `"INTEGRATION_CONNECTION_MISSING"`, `"API_KEY_INVALID"`, or `"QBD_REQUEST_ERROR"`.<br><br>By comparison, `type` is more general and categorizes the error. |
|
|
169
|
+
| `message` | `string` | The developer-friendly error message for your logs. |
|
|
170
|
+
| `endUserMessage` | `string` | The end-user-friendly error message to display in your app's UI for your end-user to see.<br><br>This value exists for _every_ error. E.g., if it's a QBD connection error, it might recommend the end-user to check that their QuickBooks Desktop is open and that they're logged in. But if a Conductor API key is expired, this message will just say "An internal server error occurred. Please try again later.". |
|
|
171
|
+
| `integrationCode` | `string` or `undefined` | The unique error code supplied by the third-party integration for errors that come from the integration (i.e., instances of `ConductorIntegrationError`). This is useful for adding special handling for specific errors from the third-party integration.<br><br>E.g., QuickBooks Desktop might return an error with `integrationCode` for something specific to its accounting logic. The integration's corresponding message for this code would be in `error.message`.<br><br>The third-party integration's error codes are not standardized, so you should not rely on this code to be the same across integrations. |
|
|
172
|
+
| `httpStatusCode` | `number` or `undefined` | The HTTP status code of the response that included the error. You probably won't need this. |
|
|
171
173
|
|
|
172
174
|
_Would any additional error properties be helpful?_ Let me know. Some potential additions: `request` for the original API request, `integrationKey` (e.g., `"quickbooks-desktop"`), or `integrationConnectionId`.
|
|
173
175
|
|
|
@@ -183,7 +185,7 @@ The error object you receive will have one of the following error types:
|
|
|
183
185
|
| `ConductorConnectionError` | There was a network problem between the client (on your server) and Conductor's servers. |
|
|
184
186
|
| `ConductorInternalError` | Something went wrong on Conductor's end. (These are rare.) |
|
|
185
187
|
|
|
186
|
-
###
|
|
188
|
+
### Specific Error Handling
|
|
187
189
|
|
|
188
190
|
If you need special handling for specific errors, you can wrap individual API calls, as shown below.
|
|
189
191
|
|
|
@@ -283,3 +285,5 @@ const server = new ApolloServer({
|
|
|
283
285
|
},
|
|
284
286
|
});
|
|
285
287
|
```
|
|
288
|
+
|
|
289
|
+
NOTE: In writing this, I realize that you might want to be alerted for integration errors unrelated to connections, such as QBD failing for accounting reasons. Perhaps I'll add the error type `ConductorIntegrationConnectionError` in the future.
|
package/dist/package.json
CHANGED
package/package.json
CHANGED