Exceptions not being generated in live production app

[Ragu Vijaykumar]

Hi all,

First of all, thank you for such a great library! Recently, we have been encountering some issues that may or may not be CouchbaseLite related, where the user's app is crashing for no known reason. Many things have been ruled out, so we are left with considering some stretch ideas at this point. One is that we have noticed in our crash manager that we never have any crashes or errors logged from Couchbase. This could mean the product is perfect :D, or it could mean that we aren't doing our part to enable exceptions passing through to a log system.

Our test was to add some blatantly wrong code in a view function and run it on the XCode debugger. Below is the snippet of code. When running in the debugger, nothing crashes and no errors are generated. The app continues to function normally, but there is no data pulled into the tableview (since the view function has code that would generate the exception).

```

    CBLView* dbView = [self.database viewNamed:@"dbVIew"];

    [dbView setMapBlock: MAPBLOCK({

        NSString* const typeKey = NSStringFromSelector(@selector(type));

            // Added array out of bounds exception generating code

            NSArray* array = @[];

            DDLogWarn(@"dbView: %@", array[1]);

            

            emit(doc[typeKey], nil);

    }) version:@"1.4.6"];

    return [sortedByDateView createQuery];

```

This code is being executed, as without the 2 lines that could cause an error, the app would function perfectly fine. 

The query is passed a pointer to an NSError* object, but that error object is still nil. 

The version of the view was incremented after adding the error lines to the view body.

We are using CouchbaseLite iOS 1.4.1 downloaded from the www.couchbase.com website.

Is there any way to propagate errors to the app so we can find issues? We do have logging enabled via the following code, but still do not see any relevant lines printing out.

        [CBLManager redirectLogging:^(NSString * _Nonnull type, NSString * _Nonnull message) {

            DDLogDebug(@"%@: %@", type, message);

        }];

        [CBLManager enableLogging:@"Database"];

        [CBLManager enableLogging:@"ViewVerbose"];

        [CBLManager enableLogging:@"QueryVerbose"];

        [CBLManager enableLogging:@"Upgrade"];

Ultimately, I guess what I'm asking is whether there is some way to enable Couchbase Lite to pass its errors on to us instead of what seems like silencing them, so that we may be able to solve our users' non-reproducible issues? Though it sounds weird, we would almost prefer to have issues caught in our crash manager (hockey) so we would at least know that there is a problem. Let me know what we need to do to make that happen :D

Cheers,

Ragu

[Jens Alfke]

On Nov 23, 2017, at 1:37 PM, Ragu Vijaykumar <ra...@lumobodytech.com> wrote:

Our test was to add some blatantly wrong code in a view function and run it on the XCode debugger. Below is the snippet of code. When running in the debugger, nothing crashes and no errors are generated. The app continues to function normally, but there is no data pulled into the tableview (since the view function has code that would generate the exception).

The map function is called within an @try…@catch block, to handle exceptions from application code. The exception will get logged as a warning. It shouldn’t cause a crash.

The query is passed a pointer to an NSError* object, but that error object is still nil. 

The map function is run while indexing the database, which is technically not the same thing as running the query. It often happens that running a query triggers indexing, if the index wasn’t up to date, but the two processes are loosely coupled, so it’s not always straightforward to pass an error up to the query call.

Of course you can add your own @try…@catch block inside your map block if you want to check for exceptions yourself.

Is there any way to propagate errors to the app so we can find issues? We do have logging enabled via the following code, but still do not see any relevant lines printing out.

That’s odd, because warnings always get logged. Could you create a test case to reproduce this?

—Jens