I have just released the first app using Couchbbase (Xamarin/C#) and I report errors to MS App Center. Now I have quite a few users getting this error:
NativeHandler.ThrowOrHandle ()
System.AggregateException: CouchbaseLiteException (LiteCoreDomain / 7): not found.
Nothing more about where the error occurred… I have tried to search for this message but have not found any useful info (some had this error if the db was corrupt - but I really doubt that is the reason here…).
So does anyone know what this could be about - and how I could narrow the search down to find and solve it?
Environment:
Couchbase Lite 2.7.1
Couchbase Mapping 1.1.0
Xamarin.Forms 4.6
sounds like the issue mainly came from Adroid 10 (75%), did you have an Android 10 device to test with? In your app, is there a way to upload logs to somewhere when an error occurs? Not sure what other logging service MS App Center can provide.
No, I also have it on iOS - and mostly the latest version. But that may well be due to the fact that the recently released Covid-19 app in DK uses the APIs in the newest release of iOS (and possibly Android) - and that may be the reason why they are over-represented…
There may be quite a few places where this could happen - which is why I am trying to understand the situation where this error could happen - and then narrow down my search…
So there is no stack trace or anything? Criticisms of that being quite a lack of information for a crash reporting service aside…this error code is used fairly extensively and I’m not sure providing a list would be productive. I will note that since it has gone all the way to a .NET exception it means that the error has bubbled up to cross the C API boundary. It is the result of the NotFound error code in LiteCore which is used when things are inexplicably not found (like a database when calling Database.Copy, or a particular revision when doing conflict resolution, etc). Without some more information (at a minimum the stack trace…it’s really wild that it’s not there in MS App Center…) I don’t think this will move forward.
Hmmm… Could be my fault that we don’t see the exception as I don’t try/catch the db operations. In the “tuning process” I have made as much code run in background threads as possible. So I guess an exception from a query in the background could behave like this. Suppose I’ll need to surround all db operations with a try/catch - and then propagate the exception up to MS App.Center if it occurs…
But you also helped by saying that this is not “ordinary” operations - but something more extraordinary going on
