Rework error responses

[tm1000]

Right now in my own usage of shippy I get errors such as:

400 Client error: `POST https://apis.fedex.com/rate/v1/rates/quotes` resulted in a `400 Bad Request` response:
{"transactionId":"..snipped..","errors":[{"code":"CURRENCY.TYPE.SELECT","message":"Please enter Currency","parameterList":[{"key":"COMMODITY_INDEX","value":"1"}]}]}

This is returned from getErrors() as a string representation of a guzzle exxception error here:

shippy/src/carriers/AbstractCarrier.php

Line 232 in b47d681

$data['__errors'][] = "{$response->getStatusCode()} {$response->getErrorMessage()}";

I'm not a super fan of turning exceptions into strings to later be returned because there can be valuable information in the exception that can be retrieved later. Instead of it being a string could we instead send the exception as is into errors? I haven't looked into why shippy stringifys these exceptions

Would you accept a PR that changes how this functions/works? __toString() is a method on all Exceptions so in the end it could still be a string it would just allow better visibility into the exception

[engram-design]

So I believe I did it this way so that consumers of Shippy don't need to roll their own handling of getting an error message for the various things Shippy does. For example, calling fetchRates() within a carrier class is going to return an array of data, but also any errors.

The other reason I did this was to have centralized error messages for calls. This covers:

• Catching application errors within Shippy
• Catching/handling Guzzle errors, like 404s, service unavailable, incorrect payload, etc
• Handling error responses from carrier APIs that are valid data returned, but the API provides us with some error descriptions

From this point of view, I wanted to combine the errors that we might get from carrier APIs as strings, with any application or Guzzle errors we get - which, as you mention, by nature give us a whole lot more context than the former.

But of course, we'd be happy to also include the exception alongside things. Possibly as a separate object to _errors? The only reason for the __errors is just to avoid any naming conflicts, like if there was an errors property returned from the carrier API. Don't forget that each carrier can define how to handle API errors like this.

More than happy if you want to put a PR together, although I'm thinking I might have a proper think about how to change this to be a little nicer handled anyway. It's very possible I've over-complicated this a bit.

I'm thinking that instead of an array return for functions like this it's a class, with data (the response from the API, if any), errors (the error response from the API, if any) and exception (if an exception occurred).