Exception handling when migrating from java SE client version 2.5.2 to 5.0.0

[syuan147]

Hello, we are migrating our Java SE client version from 2.5.2 to 5.0.0.

In the old version we have been catching exceptions like PushConnException, PushServerException, PushUserException, SubscrException. There is also a onActivityWarning() method under the ExtendedConnectionListener class.

In the new version, if I understood correctly, we get all these exception scenarios through the method ClientListener.onServerError(int errorCode, String errorMessage).

My question is, how can we catch the same exception scenarios? Is there a one-to-one matching from the old exception classes to the new errorCodes? Thanks!

[DarioCrivelli]

In the new version, the interface has changed significantly. Some notable changes are:

• All the interaction has become asynchronous. As a consequence, all the error conditions are now received only via callbacks. Synchronous exceptions upon method invocations are possible only in case of wrong parameters.
• The library now handles the connection lifecycle and attempts automatic retries upon connection errors. Hence, transient problems due to connection issues are now hidden. The library informs the application of its work through a onStatusChange callback.
• The interaction with the Server uses a different protocol (TLCP). The codes related to the various error conditions are the same, but a few new error cases have been introduced.

For these reasons, there is no direct mapping of exceptions. We assumed that, by refurbishing the application to apply to the new interface, exception handling would also be revised.
If you have a sophisticated exception handling policy and want to keep the logic, here are some notes:

• If you handled connection issues, you should now lean on the library handling and set the related parameters in ConnectionOptions. You can enforce a custom retry logic by intercepting the onStatusChange callback. We can expand on this point, if needed.
• Errors issued by the Server are still available. The cases in PushServerException and PushUserException have been merged in the same set, but have been separated based on the context. Now they are available in onServerError, if related to connection establishment, and in onSubscriptionError of the SubscriptionListener, if related to subscription requests.

[syuan147]

Thanks for reply! We used to log specific messages according to the exception type which then trigger alarms in our system.
In this case we just need to understand the error scenarios and trigger alarms accordingly.
In order to understand that,
1. In the TLCP specification (https://www.lightstreamer.com/api/ls...client/latest/), does Appendix A list all possible errorCodes we'll get through onServerError?
2. Does Appendix B list all possible errorCodes through on SubscriptionError?
3. Is there a list of all possible "status" that we get from onStatusChange callback?

[DarioCrivelli]

For 1 and 2 I confirm that the errors reported by onServerError and onSubscriptionError are related to the lists in appendix A and B, respectively.
However, some error cases are handled by the client library and hidden to the application; moreover, errors related to wrong requests are not possible if the requests are issued by the client library.
Obviously, the errors are related to the requests performed, hence some of them are not possible if the application doesn't use the related features.
A further error code for onServerError, named 61, is produced by the client library if something unexpected comes from the Server.
For the above reasons, the error listings in the documentations of onServerError and onSubscriptionError should be a better reference.

For 3, you can refer to the documentation of onStatusChange. As you can see, the state can change for many reasons.