Exception on orders not found

[momon]

I recently came across this and started testing it for a new project. Thank you for making it available.

I am not 100% sure if this is intentional but if you lookup an order that does NOT exists an exception is thrown instead of a graceful error of an entry not found.

For instance, here is a test on an order I know doesn't exists:

Error 400 reported by FastSpring's API for your GET request to the \"orders\" endpoint. Response: \"{\\\"orders\\\":[{\\\"action\\\":\\\"order.get\\\",\\\"order\\\":\\\"someorderid\\\",\\\"result\\\":\\\"error\\\",\\\"error\\\":{\\\"order\\\":\\\"Not found\\\"}}]}\"

As you can see, FS does respond with an expected Order Not Found message but the wrapper instead of relaying that message over gracefully throws an exception. I understand it may not be a common scenario to try and fetch data for an invalid order but I came across that while testing and though I would submit feedback.

Not sure if considered an improvement or not but I would have liked to get an error message or error code instead that I could manage in order to control the end user output (this might be a bit too specific to how I am trying to implement your wrapper).

Cheers.

Update: a quick workaround for this is to catch the exception like so. You can get fancy with some logic to identify the error response and provide more meaningful output based on it. In the example below all failures will return 400. This is using Code Igniter but is applicable to any other PHP framework.

try {
    $response = FastSpring::get('orders', ['someorderid']);
} catch (\Exception $e) {
    return $this->fail($e->getMessage(), 400);
}

[EmilePerron]

Hey Jose!

Thanks for the detailed issue!

FastSpring's API treats requests non-existant entries as a bad request, hence the error 400. They do include a "not found" message in the response, but they do not use the appropriate HTTP code for Not Found (404), which makes handling errors a bit more complex (as you have experienced).

Still, I agree that it would be nice for the wrapper to make it easier for its users to handle errors, even if FastSpring doesn't.

I went ahead and implemented a first attempt at improving error handling: it adds a fairly naive check on FastSpring's response and throws an Emileperron\FastSpring\Exception\NotFoundException when the response points towards a Not Found error.

You can try it out in your tests by requiring the dev-master in Composer; let me know if that helps or if you run into any issues :)

[momon]

Hey Jose!

Thanks for the detailed issue!

FastSpring's API treats requests non-existant entries as a bad request, hence the error 400. They do include a "not found" message in the response, but they do not use the appropriate HTTP code for Not Found (404), which makes handling errors a bit more complex (as you have experienced).

Still, I agree that it would be nice for the wrapper to make it easier for its users to handle errors, even if FastSpring doesn't.

I went ahead and implemented a first attempt at improving error handling: it adds a fairly naive check on FastSpring's response and throws an Emileperron\FastSpring\Exception\NotFoundException when the response points towards a Not Found error.

You can try it out in your tests by requiring the dev-master in Composer; let me know if that helps or if you run into any issues :)

Nice one! I'll be sure to give it in the next day or so and report back.