Storing Response in ApiException

[mpouris]

Beanstream API can throw a plethora of exceptions stating issues causing declined payments as well as issues with certain fields.

It may be necessary to parse these errors and map them to internal errors at a more granular level than error codes. For example, Error 314 can pertain to any payment field errors. It may be necessary to display problematic errors to the user after parsing the response.

ApiException now takes a $response parameter defaulting to null before initializing the parent Exception. The ApiException's response variable is initialized within the HttpConnector when a response is received.

[grantpalin]

Thank you for the PR. We would like to use language features where possible, and PHP exceptions do allow for inner exceptions (see http://php.net/manual/en/exception.construct.php). You are welcome to offer an amendment to the SDK base exception class if you wish, else I can code one up.

[mpouris]

Thank you for the suggestion. The logic followed for this change was to make available the response in the most appropriate exception.

As an example, the ConnectorException designated a CURL error or an unexpected response format. Whereas an ApiException is thrown when Beanstream's response error codes need to be checked. It seems appropriate to add the response into the ApiException at this point, because there exists a response, whereas there will not be a valid JSON response with a ConnectorException.

In terms of your suggestion to use a previous exception, I also had the same thought. The reason why I was deterred is because it's generally used to chain previously thrown exceptions together. Creating an exception and attaching it as a previous exception without throwing it seems to break the semantics.