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.
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
SQLITE_OK return codes
are errors, however. Recall that
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.
|Return code constant||Return code meaning|
||Internal SQLite library error ...|