Debugging¶

Strategy 1: Meaningful exception handling¶

If the API returns a 4xx or 5xx status code, it indicates that there was an error with the sent request, meaning that the transaction cannot be adequately completed.

The Guzzle HTTP component, which forms the basis of our SDK’s transport layer, utilizes numerous exception classes to handle this error logic.

The two most common exception classes are:

• Guzzle\Http\Exception\ClientErrorResponseException, which is thrown when a 4xx response occurs
• Guzzle\Http\Exception\ServerErrorResponseException, which is thrown when a 5xx response occurs

Both of these classes extend the base BadResponseException class.

This provides you with the granularity you need to debug and handle exceptions.

use Guzzle\Http\Exception\ClientErrorResponseException;

try {
    return $service->getObject('foo.jpg');
} catch (ClientErrorResponseException $e) {
    if ($e->getResponse()->getStatusCode() == 404) {
      // Okay, the resource does not exist
      return false;
    }
} catch (\Exception $e) {
    // Some other exception was thrown...
}

// Find out the faulty request
$request = $e->getRequest();

// Display everything by casting as string
echo (string) $request;

// Find out the HTTP response
$response = $e->getResponse();

// Output that too
echo (string) $response;

Strategy 2: Wire logging¶

Guzzle provides a Log plugin that allows you to log everything over the wire, which is useful if you don’t know what’s going on.

Here’s how you enable it:

composer require guzzle/guzzle

use Guzzle\Plugin\Log\LogPlugin;

$client->addSubscriber(LogPlugin::getDebugPlugin());