Chrome's higher-level SQLite API, implemented in //sql, aims to flag bugs early by DCHECKing on SQLite errors that are unlikely to occur during development. The thinking is that some SQLite errors are most likely to come from API misuse, such as bad SQL statements.

While reasonable, this approach goes against the principle that DCHECKs should only be used for invariant checking, and should never fail in real-world situations. For example, the same SQLite error code that generally indicates a bad SQL statement might be caused by database corruption.

We need to audit //sql and come up with a better error handling strategy. The new strategy should flag development errors as early as possible, subject to the constraint of using our logging APIs as intended.