You should ensure you are verifying the success of any result objects returned through completion blocks or handlers. It is also important to implement error handling for unexpected errors in addition to errors that are not the direct result of a call to the SDK.

We recommend that you implement the client's connection state update method to detect when the client loses network connectivity. Today, operations performed while the client is not connected will fail unless connectivity returns quickly. Preventing your application from operating on the client while it is offline is a best practice for ensuring your operations succeed as expected.

Objective-C and Swift both use the same approach to error reporting and handling, though the syntax differs by language.

The Chat client's errorReceived method is the first diagnostic method you should implement. This method will be called during client creation if any error occurs. If client initialization fails and a nil client is returned, this method will be called with an explanation of why the creation failed.

You must pass in a delegate on client creation in iOS even if your application changes this delegate later. This ensures that you receive this callback, since it may be called before the initial client creation method completes.

Most operations that can be performed on objects in Programmable Chat for iOS return a TCHResult object to their completion block. This includes operations against Channels, Messages, and Members. This object contains an isSuccessful method as well as an error property which will be populated with an error should the operation fail. Your application should check for this error and never disregard it. Provide a completion block to methods, even if you do not need a reference to the resulting object, to verify that your request was successful.

On iOS, connection state changes are sent to the client's delegate with the connectionStateChanged method.

On Android, all asynchronous functions receive a StatusListener whose onError(ErrorInfo) method must be implemented to receive error information. Check for these errors during your application's runtime. You should always provide a StatusListener to methods, even if you do not intend to use the resulting object, to verify that your request was successful.

The Client creation method does not return a new Client instance right away - instead, the instance gets returned in the CallbackListener's onSuccess() callback to prevent misuse.

Connection state changes are sent to the client's ChatClientListener (which you can set with client.setListener()) with the onConnectionStateChange method.

General error handling uses standard JavaScript mechanisms. Most of these library methods are asynchronous and return promises.

In the case of an error, the promise will pass an instance of the JS Error class (or it’s ancestor) to the catch handler if specified. Additionally, Twilio error classes provide a numeric error code property to make it easier to identify specific problems.

The standard way to handle errors in promise-based syntax looks like this:

client.getMessages().then(messagesPage=>{dosomethinghere}).catch(e=>{console.error('Got an error:',e.code,e.message);});

Connection state changes are surfaced via the client#connectionStateChanged event. Denied is the most important state to pay attention to, since it indicates a problem with the Access Token. The Denied state necessitates a new token.

Programmable Chat's default log level is WARNING. When evaluating errors during development or building a log for Twilio support this level must be changed to DEBUG. Some potentially critical information is logged only at the most verbose logging level.

It is also essential that logs not be truncated or optimized to show only the error line. Information before or after the lines that seem to be the important ones may prove critical for diagnosing the issue. If you have sensitive application information in the log unrelated to Twilio, you may remove or obfuscate it, but otherwise, we recommend unmodified logs.

Given full logs may contain still-valid access tokens, we do not recommend posting logs in public forums and instead suggest either 1:1 messages to Twilio support or opening a ticket.

In particular, searching your log for 4xx and 5xx errors such as 401 can be very helpful in diagnosing issues. Generally speaking, a 401 error will indicate permissions issue - either for the particular object you are interacting with or your entire session if the 401 is related to your access token.

Rate this page:

ヘルプが必要ですか？

We all do sometimes; code is hard. Get help now from our support team, or lean on the wisdom of the crowd browsing the Twilio tag on Stack Overflow.