errorResposnes from operation is never used about guzzle-services HOT 8 CLOSED

These are meant only for documentation and metadata purposes. Having Guzzle throw an exception would mean that it would require much more metadata on how to convert a response or network error into an exception class. Guzzle would also need some kind of factory to create exceptions. I've intentionally omitted throwing custom exceptions to avoid this complexity.

With that said, you could utilize this metadata by creating a subscriber that listens for errors, checks metadata for errorResponses, and throws the appropriate exception.

On Jan 1, 2015, at 4:50 PM, Michaël Gallego [email protected] wrote:

Hi,

In the Operation descriptor, there is a "errorResponses" hash that is supposed to be used. While it's read by the operation, it seems to be never used elsewhere in the code. As a consequence, user defined exception are never triggered.

Did I miss something or is the doc outdated? :)

Thanks!

—
Reply to this email directly or view it on GitHub.

from guzzle-services.

I see... What if I write a reusable subscriber? I've checked my various Guzzle 3 integrations and I actually use this all the time, so that would mean duplicate the same code everywhere. While I understand that it does not throw exception by default, at least it should have a default one :).

from guzzle-services.

What do you mean by having a default one?

On Jan 1, 2015, at 5:19 PM, Michaël Gallego [email protected] wrote:

I see... What if I write a reusable subscriber? I've checked my various Guzzle 3 integrations and I actually use this all the time, so that would mean duplicate the same code everywhere. While I understand that it does not throw exception by default, at least it should have a default one :).

—
Reply to this email directly or view it on GitHub.

from guzzle-services.

Well, having a default listener that you can attach, and that will reuse the "errorResponses" to create an exception. It won't be registered by default, but at least it removes the need to write this boilerplate code in all libraries.

from guzzle-services.

Hi,

I tried to do this this morning, unfortunately I didn't found any way to attach a listener to a command error from my client. If I hook to the "error" event, then I cannot have access to the command. Is there any way to do that simply, or am I forced to overload the __call, manually creating the command, attaching a subscriber, and trigger it?

EDIT: never mind, I had to attach the listener to the Service client, not HTTP client.

from guzzle-services.

Actually, the problem is that the current operation cannot be retrieved from a command... still trying to work around this =).

from guzzle-services.

Still no luck with this @mtdowling . Is there a simple way to add a listener that will be able to have the response AND the command that was executed (along with the errorResponses array). This is pretty necessary to do the reusable error exception listener.

from guzzle-services.

You have access to the operation information from the client that is pass around as part of each command event. You can retrieve the service description from the client and the specific operation information from the description using the name of the command.

Something like this:

use GuzzleHttp\Command\Event\ProcessEvent;

$command->getEmitter()->on('process', ProcessEvent $e) {
    $name = $e->getCommand()->getName();
    $description = $e->getClient()->getDescription();
    $operation = $description->getOperation($name);
    $errors = $operation->getErrorResponses();
    // do something with the errors.
});

from guzzle-services.