Skip to main content

Error handling

About error handling​

Every operation on the Controller takes a callback with a success and a failure method. When an operation fails, an ErrorCodeException object is passed as a parameter to onFailure.

This 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 ErrorCodeException object contains the following methods:

Note

For any server-related errors in production, getMessage() will return the following:

Error description not available in production.
Obtaining additional information

You may be able to obtain additional information that can be used during development by using the toString() method of the ErrorCodeException.

Error code enum object​

The ErrorCode enum object contains the following methods:

Recoverable errors​

Most Encap operations are divided into a start and 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.

Note

On Android, this happens when the ErrorCodeException is of type AuthenticationFailedException. The type needs to be cast before being queried for information.

You can access the remaining attempts using getRemainingAttempts(). This can be valuable for the end-user to know before they retry with a new PIN.

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 errorCode.getErrorCodeName().
  • The exception.getMessage().
  • The type of the exception exception.getClass().getName().
  • The stack exception.printStackTrace(...).
    Note

    You need to loop through all getCause()exceptions to get the full stack. Ensure that you save the .map file when building, so that it is possible to deobfuscate the stack.

  • The Encap operation the error occurred in.
  • The version of the Encap SDK and server being used.
  • The version of Android being used.
Tip

Many logging tools also make it possible to follow the order of SDK operations performed by the app. This can be valuable for recreating certain errors that are otherwise difficult to reproduce.

On this page