Thanks for the reply!
The bug's not in SQLite. We're recording in an environment where disk files
can become corrupted. Ugly, I know. I record many db files, and then a
Force of Nature comes along and scrambles the bits of some of them. I want
to detect scrambled files without crashing.
So, disabling asserts would lead to segfaults which are bad. But, asserts
aren't much better since they still crash in a polite way. I'd rather
detect the assertion and return to my caller.
--Noel
----- Original Message -----
From: "D. Richard Hipp" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, August 22, 2005 4:34 PM
Subject: Re: [sqlite] catching asserts from sqlite
On Mon, 2005-08-22 at 16:09 -0700, Noel Burton-Krahn wrote:
Sqlite throws an assert() and crashes when it reads a corrupt db.
(Sqlite
is fine, our recording medium is flaky.) I'd like to catch the assert()
and
report an error without crashing.
The problem is, sqlite throws assert() from functions that don't return
an
error code. So, there's no way to simply return an error and unwind the
function call stack. So, I can see a few options, none of them good
First off, if you are throwing asserts in a production application,
it means you are compiling SQLite wrong. You should compile with
the -DNDEBUG=1 option which will disable the asserts and make SQLite
run over twice as fast.
On the other hand, when you turn off asserts and you run across this
particular bug, the program will segfault instead of giving you an
error message. That is what asserts are for, really: debugging.
If you are throwing an assert, that means you have found a bug. Please
file a bug report with the specific version of SQLite you are using,
the SQL statement you were running, and the complete text of the assert
that failed. Attach the database that caused the assert if posssible.
Or better, provide a short SQL script that causes the assert to fail
when run from the command-line client.
We'll try to get to it...
--
D. Richard Hipp <[EMAIL PROTECTED]>
