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

Provide error enumeration instead of strings for error handling #59

Open
d4nielRV opened this issue Sep 30, 2020 · 1 comment
Open

Provide error enumeration instead of strings for error handling #59

d4nielRV opened this issue Sep 30, 2020 · 1 comment
Labels
android fixed-future-release Bug/feature will be out in an undetermined upcoming release. ios

Comments

@d4nielRV
Copy link

Is your feature request related to a problem? Please describe.
As part of the Flows & Errors Handling documentation: https://developers.klarna.com/documentation/in-app/overview/inapp-sdk-flows/ you provide a list of cases which should be handled by the developer such as Rejected Authorize or Invalid Client Token. In that documentation:

func klarnaFailed(inPaymentView paymentView: KlarnaPaymentView, withError error: KlarnaPaymentError) {
        if error.name == "InvalidClientTokenError" {
          // Client token used to initialize the SDK is invalid.
           // Merchant should get a valid client token and use it to initialize the SDK again.
        }
    }

In the callback klarnaFailed you provide as parameter an instance of KlarnaPaymentError which contains a couple of attributes: action and message. Those properties have to be checked in order to detect the kind of error, but since they are Strings we don't have a list of the errors that could be returned by the SDK.

Describe the solution you'd like
Defining an enum the kind of error would let us to keep a clear code to handle those errors. For example, following your documentation, the error.name ShowFormFalseError is being used for multiple errors depending on the action (Load, Authorize, etc.).

Current status:

func klarnaFailed(inPaymentView paymentView: KlarnaPaymentView, withError error: KlarnaPaymentError) {
        if error.action == "Authorize" && error.name == "ShowFormFalseError" {
           // user is rejected when authorizing the payment.
           // Merchant should remove the Klarna view and stop the payment process.
        } else if error.action == "Load" && error.name = "ShowFormFalseError" {
          // The selected payment method is invalid.
           // Merchant should set a valid payment method for SDK and initialize the SDK again.
        }
    }

Our proposal:

func klarnaFailed(inPaymentView paymentView: KlarnaPaymentView, withError error: KlarnaPaymentError) {
   switch(error.type) {
      case .invalidPaymentMethod:
         // The selected payment method is invalid.
         // Merchant should set a valid payment method for SDK and initialize the SDK again.
      case .rejectedAuthorization:
        // user is rejected when authorizing the payment.
        // Merchant should remove the Klarna view and stop the payment process.
   }
}

Actually comparing Strings is not so secure solution because in case any developer or even you as SDK provider has any typo, the error handling will fail.

Describe alternatives you've considered
At least provide a list of possible values for both action and name properties.

Additional context
N/A

@gbanfalvikl
Copy link
Contributor

Hi!

We'd love to provide an enumeration for error types. This is for our sake too. However, a number of them (most, in fact) come from the backend and we can't insure that all the other cases are (or will be) covered.

We're looking into offering some form of string typealias for error type with the most common values being predefined – effectively making integration look a lot like your code.

This might take a little bit of time, however. We'll keep the issue open and update you as it comes out!

@gbanfalvikl gbanfalvikl added android fixed-future-release Bug/feature will be out in an undetermined upcoming release. ios labels May 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
android fixed-future-release Bug/feature will be out in an undetermined upcoming release. ios
Projects
None yet
Development

No branches or pull requests

2 participants