Errors

Since there are different approaches to errors, exceptions and callbacks used in Android (Java, Kotlin) and iOS (ObjC, Swift), CM SDK has to have different methods to communicate that something went wrong in particular method.

Android

An android version of CM SDK is reporting error states to application using exceptions. CMException is super class of all checked exceptions that are used in CM SDK. CM SDK usually sets exception that caused the problem as cause to instances of CMException, so it can be used, checked or inspected if needed.

CMException contains error code, that can be used by application to handle various error states. Subclasses of CMException contains public static final int fields with error codes used for particular exception. The only exception to this rule is CMServerError, which use codes returned by CASE server. CMError contains definitions and description of these error codes.

Every listener interface for asynchronous methods has exception parameter in failure method. It is used to deliver errors to application from background thread. All asynchronous code in CM SDK is wrapped into try-catch block with catch(Exception) as last catch block. It is done to prevent application crashes due to error on background thread. If anything goes wrong, CMException with INTERNAL_ERROR code is returned. Runtime exceptions are not caught.

iOS

An iOS version of CM SDK is reporting error states to application using errors.

Swift methods are returning instance of Result with failure defined as CSMError enum. Each enum item has associated values that contains error code. Error codes are defined in respective enum for each item. Other associated values are message with description of failure and underlying error that caused failure.

Every asynchronous method from CM SDK requires completion block as last parameter. Completion blocks accepts Swift.Result with CSMError as parameter.

Continue to Logging