Skip to content
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

Open
ejegg opened this issue Sep 17, 2015 · 5 comments
Open

Use Exception subclasses or error codes #14

ejegg opened this issue Sep 17, 2015 · 5 comments

Comments

@ejegg
Copy link

ejegg commented Sep 17, 2015

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.

@shrakuma
Copy link

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

@kailight
Copy link

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.

@bmeynell
Copy link

bmeynell commented Feb 2, 2016

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 Exception's thrown or are they all a simple generic Exception class? For example, what if Amazon is down and cannot be communicated with? There's the "service status" API call but if the Amazon API is down that probably defaults the purpose of that call. Looking at the code I saw an invokePost method which looked like the right spot for these cases. If so, is the recommended way to wrap each API call like so?

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 ...
}

@mablae
Copy link

mablae commented Sep 20, 2016

@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?

@lotsofbytes
Copy link

frustrated without error code.

the "charge" method returns an exception because of Suspended caused by InvvalidPaymentMethod
"The Order Reference is in the Suspended State. It should be in the Draft or Open State"

I want to identify this with the exception error code but currently only the string above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants