Using SQLite

Result Codes and Error Codes

You may have noticed that I’ve been fairly quiet about the result codes that can be expected from a number of these API calls. Unfortunately, error handling in SQLite is a bit complex. At some point, it was recognized that the original error reporting mechanism was a bit too generic and somewhat difficult to use. To address these concerns, a newer “extended” set of error codes was added, but this new system had to be layered on top of the existing system without breaking backward compatibility. As a result, we have both the older and newer error codes, as well as specific API calls that will alter the meaning of some of the codes. This all makes for a somewhat complex situation.

Standard Codes

Before we get into when things go wrong, let’s take a quick look at when things go right. Generally, any API call that simply needs to indicate, “that worked,” will return the constant SQLITE_OK. Not all non-SQLITE_OK return codes are errors, however. Recall that sqlite3_step() returns SQLITE_ROW or SQLITE_DONE to indicate specific return state.

Table 7-2 provides a quick overview of the standard error codes. At this point in the development life cycle, it is unlikely that additional standard error codes will be added. Additional extended error codes may be added at any time, however.

Table 7-2. SQLite standard return codes

Return code constant	Return code meaning
SQLITE_OK	Operation successful
SQLITE_ERROR	Generic error
SQLITE_INTERNAL	Internal SQLite library error ...