I have a user getting an unhandled SQLite exception while saving data to the SQLite database that my app uses. I can login as the user and see their data and attempt the same steps in the iOS Simulator (as the data is pulled down from the cloud) and I am unable to reproduce the issue.
Now I know I should wrap a try/catch around my SQLExecute statements - and for the most part I do - but obviously I’ve missed a few. But in any case I would still like to be able to decipher the error that my user is getting.
Here’s how the relevant part of the stack looks:
Would the SQLiteErrorRK18 refer to an SQLite error code and, if so, is that error code 18 meaning that a string is too big? I’m just guessing here. Any help gratefully appreciated.
The SQLite docs state that string and blob columns can be 1,000,000,000 bytes (1Gb!!!); mine are just from text fields so there’s no chance they would be approaching that size. The docs also nominate a limit of 1Mb on the SQL statement itself but mine isn’t long or complicated. So I’m wondering whether this error 18 guess is off the mark.
I’ve managed to reproduce the issue in the iOS Simulator with the client’s data. It turns out that it was a foreign key exception. So while I can trap for it in a try/catch, and avoid the UnhandledException event and resulting app crash, I can’t see a solid way to know the type of exception. SQLiteException.ErrorNumber is set to 0 in the catch. SQLiteException.Reason has some text about the foreign key exception but comparing text doesn’t seem very future-proof.
Is there a proper way to examine SQLiteDatabase exceptions?