Improve error handling

[gcatanese]

When a validation error 422 is returned by the API

{
  "type": "https://docs.adyen.com/errors/validation",
  "title": "The request is missing required fields or contains invalid data.",
  "status": 422,
  "detail": "It is mandatory to specify a legalEntityId when creating a new account holder.",
  "invalidFields": [{"name": "legalEntityId", "message": "legalEntityId is not provided"}],
  "errorCode": "30_011"
}

the library doesn't raise an error, but it returns instead AdyenResult: it is then responsibility of the code calling the client to inspect the AdyenResult object and understand the type of error.

This PR updates the logic in client.rb to convert 400, 422 and 500 responses in the corresponding error.

[gemini-code-assist]

Summary of Changes

Hello @gcatanese, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly improves the robustness and clarity of error handling within the Adyen Ruby client. By transitioning from returning generic result objects to raising specific exceptions for common API error codes (400, 422, and 5xx), it allows developers to more effectively catch and manage different types of API failures. This change streamlines error management, making the client more predictable and easier to integrate into applications that require precise error identification.

Highlights

• Enhanced Error Handling: The client now raises specific exceptions for HTTP 400, 422, and 5xx status codes, moving away from returning a generic AdyenResult object for these error types.
• New Error Types: Introduced Adyen::FormatError for 400 responses, Adyen::ValidationError for 422 responses, and Adyen::ServerError for 5xx responses, providing more granular error identification.
• Refactored Error Classes: The Adyen::FormatError class was updated to specifically handle 400 errors, and a dedicated Adyen::ValidationError class was created for 422 errors, replacing a previous, less specific definition.
• Comprehensive Testing: New test cases have been added to verify that the correct exceptions (Adyen::FormatError and Adyen::ValidationError) are raised with appropriate details for 400 and 422 API responses.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request significantly improves error handling by raising exceptions for 400, 422, and 5xx responses, which is a great change. The implementation is solid, and the new tests cover the client-side error cases well. I've provided a few suggestions to make the error handling even more robust by preserving the specific 5xx status code, correcting a minor typo in a test description, and adding test coverage for the new server-side error handling.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
18.6% Duplication on New Code

See analysis details on SonarQube Cloud