Skip to main content

Error handling

About error handling​

When an operation on the EncapController fails, the .failure case will contain the ErrorResult.

The ErrorResult object contains important information that the app can use to determine how to continue the flow. It can also be used to help guide the end-user on how to resolve the issue.

In a production app, logging the right error information when errors occur can play a crucial role in finding bugs. It can also assist with corner cases that would otherwise be difficult to find and solve without the log.

How does error handling work?​

The ErrorResult object contains the following properties:

Note

For any server-related errors in production, the technicalDescription property will return the following:

Error description not available in production.

Examples​

  • An example of error handling:
    Example: Error handling
    case .failure(let error):
        switch error.errorCode {
        case .serverErrorLockedByAdmin:
                message = "The registration was locked down by by admin / customer support"
        @unknown default:
                message = "An unexpected error has occurred"
        }    
    }
  • An example of getting the underlyingError from the errorResult:
    Example: Getting the underlying error
    case .failure(let error):
        // Example of getting the underlyingError from the ErrorResult
        if let underlyingError = error.underlyingError {
            log(underlyingError)    
        }
    }
    Our recommendation

    We recommended that you log the underlyingError when present, as this provide useful insights into the cause of the error.

Recoverable errors​

Most Encap SCA operations are divided into a start and a finish call.

Typically, if a finish call fails, then the app must restart the process with a new start call before attempting the finish call again. However, in some cases, the app can retry the finish call directly without having to do this.

To determine whether this is possible, you can check the return value of the property isRecoverableError:

  • If true, then the app or end-user can retry the same finish call without restarting the flow.
  • If false, then the app must restart the process with a new start call before attempting the finish call again.
Example

For example, the error clientErrorInvalidInputFormat allows the app to retry the same finish call without restarting the flow.

Limited retries​

Certain types of recoverable errors may only have a limited amount of retries, such as when an incorrect PIN is entered.

In these cases, isRecoverableError will still return true, but the error object will include details about how many more retry attempts are allowed.

For a full list of recoverable errors, see the Recoverable errors section on the SDK error codes page.

Logging errors​

We recommend that you implement proper error logging procedures, so that you can obtain valuable information about errors when they occur.

This information allows us to identify and resolve the issue faster when you report it to us.

The most valuable details you can provide us are:

  • The error code (errorCode).
  • The technical description (technicalDescription).
  • The underlying error (underlyingError).
  • The Encap operation the error occurred in.
  • The version of the Encap SDK.
On this page