-
-
Notifications
You must be signed in to change notification settings - Fork 614
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix gocardless error handling #439
Conversation
handleGoCardlessError(response); | ||
let response; | ||
try { | ||
response = client.deleteRequisition(requisitionId); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: You can return this response directly rather than declaring "response" outside of the try.
I think the last return response;
is unreachable due to handleGoCardlessError always throwing
Same with the others
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think l prefer leaving it as-is makes any expandability in the future a little easier, and IMO makes the function slightly easier to read. They're tiny little functions but my go to quick check for return value when reading tends to be the bottom.
- Stuff happens
- Handle errors
- Default return case for success
As opposed to
- Stuff happens and returns if success
- Error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair. LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small nit, but LGTM
* fix gocardless error handling * release note * remove redundant tests * tcrasset feedback
Helps with #431
It looks like GoCardless error handling wasn't working at all as
handleGoCardlessError
was never reached when client.${method} threw an error.Cheking the GCL docs, there is no behaviour defined that would return a 200 response with an error status code so Axios should always throw an error.
This changes fixes that, and allows the basic rate limit error to be sent back to the client.