How to prevent Android SQLite from dumping stack trace to logcat?

Question

On Android 2.3.3 I'm doing a bulk import into one of my SQLite tables, using the API method:

SQLiteDatabase.insert(String table, String nullColumnHack, ContentValues values)

It works fine, but if there is a database error with any row (e.g. constraint error) a full stack trace is written to Android Logcat which quickly fills up.

How can I turn off this stack trace?

I already handle any Exception being thrown but the Logcat is being polluted from within the SQLite library code.

I am worried about performance on mobile devices.

• transactions for import are enabled already
• preloaded DB is impossible because data might change

Constraints should be enforced and I will handle violation, but 20 line stack traces in Logcat for each violation multiplied by hundreds of violations is what I want to turn off.

Unfortunately I also cannot use advanced conflict handling introduced with Android Froyo because app must also run on older devices.

Cheers.

Answer 1

OK, I just found the solution as follows:

I have to use a different API method (not SQLiteDatabase.insert()):

SQLiteDatabase.insertOrThrow(String table, String nullColumnHack, ContentValues values)

Now, the exception is thrown from the SQLite library, as expected and no stack trace is dumped.

Answer 2

Just filter out any stuff you're not interested in, based on the tag or the process ID. You can do it easily in the Logcat viewer in Eclipse, or if you're using Logcat on the command line the instructions are here.

Answer 3

It's not pollution. It's the purpose of LogCat to register everything that's going on on the device / emulator.

If you want to filter out your LogCat, it's possible in Eclipse (you can filter by log tag, by pid, or by log level), thus providing a way to "remove" unwanted exceptions from a LogCat window.

EDIT If the issue is performance (according to your comments), I don't think you should worry.

• If you find bad performances, you'll gain A LOT more by enabling transactions on your batch insert.
• Also, if it's to insert "starting data" for your application, have you considered shipping the apk with a pre-loaded database? Instead of inserting everything at run-time, you could just copy an existing database that you prepared yourself. No constraint problem anymore, and almost instant start for your users. Of course, if it's dynamic batch insert (based on user entry or external parameters defined at runtime), it's not possible.