Page 1 of 3 123 LastLast
Results 1 to 10 of 22

Thread: Exception [iOS]

  1. #1

    Exception [iOS]

    Very often get next exception:

    Code:
    [iSLRequestResult checkAndRaiseExceptionForClient:session:description:]
    in LSThreadPoolThread


    with stack


    Code:
    0                                   0x063a3b74 0x0 + 104479604,
    1                                   0x001fb39d main + 0,
    2                                   0x004416e5 -[iSLSession addTable:adapter:group:schema:selector:mode:requestedBufferSize:requestedMaxFrequency:snapshot:] + 168,
    3                                   0x00448fb3 -[LSClient subscribeTable:] + 1838,
    4                                   0x0044b131 -[LSClient resubscribeAll] + 584,
    5                                   0x0044addb -[LSClient backgroundResubscribeAll] + 9
    Is it normal? What should I do?
    Sure, I've wrapped in try/catch case, but it's very irritating when debugger stops every time

  2. #2
    Administrator
    Join Date
    Feb 2012
    Location
    Bologna, Italy
    Posts
    75
    Hello Dmitry,

    the exception is thrown when the client is automatically resubscribing after a reconnection with the server. To understand the problem you can activate the client logging, adding the following line to your app delegate:

    [LSLog enableSourceType:LOG_SRC_CLIENT];

    On the console log you will see the full description of the exception. Please report it here for further investigation.
    Best regards,

    Gianluca

  3. #3

    Post

    API calls:
    Code:
    
    unsubscribeTables
    subscribeTableWithExtendedInfo 
    Log:
    2014-11-10 13:13:40.596 XXX[2410:1099797] <Thread 0x1773d960> MyClassLSContainer 0x16067c70: exception: 'Server exception' caught with code: -1, reason: 'Lightstreamer error received: -1 Incorrect instrument setup' while adding table to session
    Last edited by Dmitry Sazanovich; November 11th, 2014 at 07:40 AM.

  4. #4
    Administrator
    Join Date
    Feb 2012
    Location
    Bologna, Italy
    Posts
    75
    Hello Dmitry,

    the exception you see is actually caused by an error returned by the adapter, when trying to subscribe. Negative error codes are provider by the adapter, and in particular here the error is -1 with description "Incorrect instrument setup". You should check with your adapter's developer to understand what is causing this error.

    Hope this helps.
    Best regards,

    Gianluca

  5. #5
    Quote Originally Posted by gianluca.bertani View Post
    Hello Dmitry,

    the exception you see is actually caused by an error returned by the adapter, when trying to subscribe. Negative error codes are provider by the adapter, and in particular here the error is -1 with description "Incorrect instrument setup". You should check with your adapter's developer to understand what is causing this error.

    Hope this helps.
    Best regards,

    Gianluca
    Thanks for your answer!

    I know that server side can manage it, but I'm strongly sure that library mustn't throw exceptions.
    Last edited by Dmitry Sazanovich; November 11th, 2014 at 03:14 PM.

  6. #6
    Administrator
    Join Date
    Feb 2012
    Location
    Bologna, Italy
    Posts
    75
    Hello Dmitry,

    throwing an exception is not a bug. Exception handling is a fundamental part of many object oriented programming languages. Specifically, it is a construct designed to avoid the if-then-elseif chaining that happens when checking for errors in structured languages. See en.wikipedia.org/wiki/Exception_handling for further information.

    The Lightstreamer client library for iOS makes use of exceptions to signal a variety of error conditions, between them: absence of connection, connection errors, server errors, etc. In your case, this exception is thrown by the subscription API during an automatic resubscription procedure, which happens on a background thread. Since exceptions thrown from a background thread cannot reach the user's code, they are caught locally and logged, so that they can still be diagnosed.

    Feel free to ask for any clarification
    Best regards,

    Gianluca

  7. #7
    I disagree with you.

    Read This Fine explanation http://stackoverflow.com/a/324805
    also, exception has one annoying trait - it works also as breakpoint. I can't disable this "breakpoint".

    The Lightstreamer client library for iOS makes use of exceptions to signal a variety of error conditions, between them: absence of connection, connection errors, server errors, etc
    --- the Lightstreamer client library for iOS has delegate methods for this reasons. Why do not use them?
    Last edited by Dmitry Sazanovich; November 12th, 2014 at 11:30 AM.

  8. #8
    Administrator
    Join Date
    Feb 2012
    Location
    Bologna, Italy
    Posts
    75
    Hello Dmitry,

    if you mean the common "All Exceptions" breakpoint of Xcode, of course you can disable it:
    1) select the Breakpoint Navigator on the left pane of Xcode;
    2) right-click (or cmd-click) the "All Exceptions" breakpoint;
    3) select "Delete Breakpoint".

    Apple has its point on warning developers about resource usage, nonetheless they use exceptions in first instance in situations equivalent to our library. For example, read the discussion of the writeData method of NSFileHandle, a Foundation class available since iOS 2.0:

    "This method raises an exception if the file descriptor is closed or is not valid, if the receiver represents an unconnected pipe or socket endpoint, if no free space is left on the file system, or if any other writing error occurs."

    Moreover, an argument about resource consumption may have been reasonable 6 years ago, when the article you linked was written. Modern Ax processors provide enough memory and bandwidth to consider the resource usage of exception handling negligible. In fact, I could not find this line "Exceptions are resource-intensive in Objective-C" in current documentation. My guess is that it has been removed since long.

    Whether to use exceptions or not is a design choice that is up to the developer of the library. Our library makes use of both exceptions and asynchronous notifications, but not interchangeably. Asynchronous notifications usually signal problems on the streaming connection, because events on the streaming connection are typically asynchronous. While exceptions usually signal problems on the control connection (i.e. operations like subscription and unsubscription), because control operations are typically synchronous.

    There are situations where a simple @catch may save some code and provide better clarity and maintainability of your code base. For example, when doing a sequence of control operations:


    @try {
    tableKey1= [client subscribeTable:tableInfo1 delegate:self useCommandLogic:NO];
    tableKey2= [client subscribeTable:tableInfo2 delegate:self useCommandLogic:NO];
    [client unsubscribeTable:tableKey3];

    // Update UI

    } @catch (LSPushConnectionException *e) {
    // Alert user
    // Reschedule operations for later

    } @catch (NSException *) {
    // Alert user
    // Log for later analysis
    }


    An hypothetical version of our library supporting the Cocoa pattern of NSError would require a step by step check of the error for each operation:


    NSError *error= nil;

    tableKey1= [client subscribeTable:tableInfo1 delegate:self useCommandLogic:NO error:&error];
    if (error) {
    if (/* error is a connection error */) {
    // Alert user
    // Reschedule operations for later
    } else { // error is not a connection error
    // Alert user
    // Log for later analysis
    }

    } else { // !error

    error= nil;
    tableKey2= [client subscribeTable:tableInfo2 delegate:self useCommandLogic:NO error:&error];
    if (error) {
    if (/* error is a connection error */) {
    // Alert user
    // Reschedule operations for later
    } else { // error is not a connection error
    // Alert user
    // Log for later analysis
    }

    } else { // !error
    ...


    You may find a trick or two to streamline the error checking, but the simplicity and clarity of a @try-@catch block may be hard to achieve with different means. Anyway, let's agree that code style is a matter of taste.

    Best regards,

    Gianluca

  9. #9
    Sorry, but I strongly disagree with you that it's normal behaviour.


    First of all, I would add method to LSTableDelegate to handle this situation, or " Cocoa pattern of NSError".

    And as I see, I can't hope for changes

    Sorry for disturbing.

  10. #10
    Administrator
    Join Date
    Feb 2012
    Location
    Bologna, Italy
    Posts
    75
    Hello again Dmitry,

    besides our different views on the use of exceptions, your main issue seems to be that your are not notified of the resubscription failure. If this is the case, I agree this behavior of the library may be improved.

    At the moment, the library tries again to resubscribe the tables each time it reconnects. If a resubscription fails, it is simply logged and then retried the next time. The library could instead notify your delegate of the exception (instead of logging it) and give up resubscribing the table.

    Let me know if this would be a better behavior for your application.
    Best regards,

    Gianluca

 

 

Similar Threads

  1. Connection timed out on empty credentials on iOS [iOS]
    By Anatoly Gurfinkel in forum Client APIs
    Replies: 9
    Last Post: July 6th, 2015, 05:24 PM
  2. iOS client API encoding issue
    By LS_Developer in forum Client APIs
    Replies: 3
    Last Post: February 14th, 2013, 03:47 PM
  3. LS iOS LSCommand mode sample
    By mibrahim.youxel in forum Client APIs
    Replies: 4
    Last Post: December 3rd, 2012, 10:49 AM
  4. Bandwidth in iOS
    By bor306 in forum Client APIs
    Replies: 7
    Last Post: July 11th, 2012, 03:28 PM
  5. iOS Client Library Preview
    By Alessandro in forum Client APIs
    Replies: 0
    Last Post: March 28th, 2011, 04:06 PM

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT +1. The time now is 08:42 PM.