-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Exception subclasses or error codes #14
Comments
Elliott, thanks for your suggestion. I will review the parsing of the error messages request and get back to you once we discuss in our sprint |
I am working with this library and its very hard to handle the errors - have to dig in the arrays to understand why payments get stuck. Please note that not all errors are getting handled with exceptions, such as invalid payment method error that is in some other place in XML. |
Agreed. I believe I am looking for similar answers. I arrived here in search of the best practice for error handing the API calls. For example, is any sort of specific try {
$response = $this
->amazonPay
->setOrderReferenceDetails(array(
'amazon_order_reference_id' => $order->getAmazonReferenceId(),
'seller_order_id' => $order->getAmazonOrderId(),
'amount' => $order->getTotal(),
'currency_code' => 'USD',
'seller_note' => 'Hello World.',
'store_name' => 'Our Shop!',
));
} catch (\Exception $e) {
// Perform error handing here ...
} |
@bmeynell This library is a total mess. 😄 It does not throw exceptions at all. You have to "ask" the client if there was an error on an boolean var. When implementing an Exception Approach it would be nice to wrap them into super classes Like ClientException == 4xx and ServiceException = 5xx ClientException would then wrap around the response object and extract useful messages and and Error codes from it? |
frustrated without error code. the "charge" method returns an exception because of Suspended caused by InvvalidPaymentMethod I want to identify this with the exception error code but currently only the string above. |
Users need a better way to determine error categories than parsing error messages. One good solution would be problem-specific Exception types, such as BadMethodCallException for missing parameters or a hypothetical PayWithAmazon\BadSignatureException for an improperly-signed incoming IPN message. Alternatively, the SDK could define a set of integer constants to use as error codes.
The text was updated successfully, but these errors were encountered: