Exceptions and Errors
Python uses exceptions to indicate an error has
happened.  The SQLite library uses integer error codes.  APSW maps between the two
systems as needed.  Exceptions raised in Python code called by SQLite
will have that exception present when control returns to Python, and
SQLite will understand that an error occurred.
Chaining
When an error is reported to SQLite, it may take further actions. For example errors in VFS can result in error recovery attempts, while an error in a window function step method will result in the final method being called to do clean up. Your code implementing those could also have additional exceptions.
When multiple exceptions occur in the same SQLite control flow then they will be chained. Python’s traceback printing code will show all the exceptions.
Unraisable
There are a few places where it is not possible for a Python exception
to be reported to SQLite as an error, and Python C code does not allow
destructors to report exceptions.  These exceptions are reported via
sys.unraisablehook(), and if that is not present then
sys.excepthook().
sqlite3_log is also called so that you will have the context of when the exception happened relative to the errors SQLite is logging.
Exception Classes
- exception apsw.Error
- This is the base for APSW exceptions. 
- Error.result
- For exceptions corresponding to SQLite error codes codes this attribute is the numeric error code. 
- Error.extendedresult
- APSW runs with extended result codes turned on. This attribute includes the detailed code. - As an example, if SQLite issued a read request and the system returned less data than expected then - resultwould have the value SQLITE_IOERR while- extendedresultwould have the value SQLITE_IOERR_SHORT_READ.
- Error.error_offset
- The location of the error in the SQL when encoded in UTF-8. The value is from sqlite3_error_offset, and will be -1 when a specific token in the input is not the cause. 
APSW specific exceptions
The following exceptions happen when APSW detects various problems.
- exception apsw.ThreadingViolationError
- You have used an object concurrently in two threads. For example you may try to use the same cursor in two different threads at the same time, or tried to close the same connection in two threads at the same time. - You can also get this exception by using a cursor while it is already inside execution such as executing a new query while inside a function called by that cursor. It is recommended to use - Connection.execute()and- Connection.executemany()instead of using cursors directly.
- exception apsw.ForkingViolationError
- See - apsw.fork_checker().
- exception apsw.IncompleteExecutionError
- You have tried to start a new SQL execute call before executing all the previous ones. See the execution model for more details. 
- exception apsw.ConnectionNotClosedError
- This exception is no longer generated. It was required in earlier releases due to constraints in threading usage with SQLite. 
- exception apsw.ConnectionClosedError
- You have called - Connection.close()and then continued to use the- Connectionor associated- cursors.
- exception apsw.CursorClosedError
- You have called - Cursor.close()and then tried to use the cursor.
- exception apsw.BindingsError
- There are several causes for this exception. When using tuples, an incorrect number of bindings where supplied: - cursor.execute("select ?,?,?", (1,2)) # too few bindings cursor.execute("select ?,?,?", (1,2,3,4)) # too many bindings - You are using named bindings, but not all bindings are named. You should either use entirely the named style or entirely numeric (unnamed) style: - cursor.execute("select * from foo where x=:name and y=?") 
- exception apsw.ExecutionCompleteError
- Execution of the statements is complete and cannot be run further. 
- exception apsw.ExecTraceAbort
- The execution tracer returned False so execution was aborted. 
- exception apsw.VFSNotImplementedError
- A call cannot be made to an inherited Virtual File System (VFS) method as the VFS does not implement the method. 
- exception apsw.VFSFileClosedError
- The VFS file is closed so the operation cannot be performed. 
- exception apsw.NoFTS5Error
- The FTS5 extension is not present in SQLite. 
- exception apsw.InvalidContextError
- Context is no longer valid. Examples include: - Using an - IndexInfooutside of the- VTTable.BestIndexObject()method
- Using a registered - FTS5Tokenizerwhen the underlying tokenizer has been deleted/replaced
- Using - Connection.vtab_config()when not inside- VTModule.Create()
- Using a - TableChangeoutside of a- apply()conflict handler, or when no longer the current- Changeset.iter()item
 
SQLite Exceptions
The following lists which Exception classes correspond to which SQLite error codes.
General Errors
- exception apsw.SQLError
- SQLITE_ERROR. The standard error code, unless a more specific one is applicable. 
- exception apsw.MismatchError
- SQLITE_MISMATCH. Data type mismatch. For example a rowid or integer primary key must be an integer. 
- exception apsw.NotFoundError
- SQLITE_NOTFOUND. Returned when various internal items were not found such as requests for non-existent system calls or file controls. 
Internal Errors
- exception apsw.InternalError
- SQLITE_INTERNAL. (No longer used) Internal logic error in SQLite. 
- exception apsw.ProtocolError
- SQLITE_PROTOCOL. (No longer used) Database lock protocol error. 
- exception apsw.MisuseError
- SQLITE_MISUSE. SQLite library used incorrectly - typically similar to ValueError in Python. Examples include not having enough flags when opening a connection (eg not including a READ or WRITE flag), or out of spec such as registering a function with more than 127 parameters. 
- exception apsw.RangeError
- SQLITE_RANGE. (Cannot be generated using APSW). 2nd parameter to sqlite3_bind out of range 
Permissions Etc
- exception apsw.PermissionsError
- SQLITE_PERM. Access permission denied by the operating system. 
- exception apsw.ReadOnlyError
- SQLITE_READONLY. Attempt to write to a readonly database. 
- exception apsw.CantOpenError
- SQLITE_CANTOPEN. Unable to open the database file. 
- exception apsw.AuthError
- SQLITE_AUTH. - Authorizationdenied.
Abort/Busy Etc
- exception apsw.AbortError
- SQLITE_ABORT. Callback routine requested an abort. 
- exception apsw.BusyError
- SQLITE_BUSY. The database file is locked. Use - Connection.set_busy_timeout()to change how long SQLite waits for the database to be unlocked or- Connection.set_busy_handler()to use your own handler.
- exception apsw.LockedError
- SQLITE_LOCKED. Shared cache lock. 
- exception apsw.InterruptError
- SQLITE_INTERRUPT. Operation terminated by sqlite3_interrupt - use - Connection.interrupt().
- exception apsw.SchemaChangeError
- SQLITE_SCHEMA. The database schema changed. A - prepared statementbecomes invalid if the database schema was changed. Behind the scenes SQLite reprepares the statement. Another or the same- Connectionmay change the schema again before the statement runs. SQLite will retry before giving up and returning this error.
- exception apsw.ConstraintError
- SQLITE_CONSTRAINT. Abort due to constraint violation. 
Memory/Disk
- exception apsw.NoMemError
- SQLITE_NOMEM. A memory
- allocation failed. 
 
- exception apsw.IOError
- SQLITE_IOERR. A disk I/O error occurred. The extended error code will give more detail. 
- exception apsw.CorruptError
- SQLITE_CORRUPT. The database disk image appears to be a SQLite database but the values inside are inconsistent. 
- exception apsw.FullError
- SQLITE_FULL. The disk appears to be full. 
- exception apsw.TooBigError
- SQLITE_TOOBIG. String or BLOB exceeds size limit. You can change the limits using - Connection.limit().
- exception apsw.NoLFSError
- SQLITE_NOLFS. SQLite has attempted to use a feature not supported by the operating system such as large file support. 
- exception apsw.EmptyError
- SQLITE_EMPTY. Not currently used. 
- exception apsw.FormatError
- SQLITE_FORMAT. (No longer used) Auxiliary database format error. 
- exception apsw.NotADBError
- SQLITE_NOTADB. File opened that is not a database file. SQLite has a header on database files to verify they are indeed SQLite databases. 
Augmented stack traces
When an exception occurs, Python does not include frames from non-Python code (ie the C code called from Python). This can make it more difficult to work out what was going on when an exception occurred for example when there are callbacks to collations, functions or virtual tables, triggers firing etc.
This is an example showing the difference between the tracebacks you would have got with earlier versions of apsw and the augmented traceback:
import apsw
def myfunc(x):
  1/0
con=apsw.Connection(":memory:")
con.create_scalar_function("foo", myfunc)
con.create_scalar_function("fam", myfunc)
cursor=con.cursor()
cursor.execute("create table bar(x,y,z);insert into bar values(1,2,3)")
cursor.execute("select foo(1) from bar")
| Original Traceback | 
|---|
| Traceback (most recent call last):
  File "t.py", line 11, in <module>
    cursor.execute("select foo(1) from bar")
  File "t.py", line 4, in myfunc
    1/0
ZeroDivisionError: integer division or modulo by zero
 | 
| Augmented Traceback | 
|---|
| Traceback (most recent call last):
  File "t.py", line 11, in <module>
    cursor.execute("select foo(1) from bar")
  File "apsw.c", line 3412, in resetcursor
  File "apsw.c", line 1597, in user-defined-scalar-foo
  File "t.py", line 4, in myfunc
    1/0
ZeroDivisionError: integer division or modulo by zero
 | 
In the original traceback you can’t even see that code in apsw was involved. The augmented traceback shows that there were indeed two function calls within apsw and gives you line numbers should you need to examine the code. Also note how you are told that the call was in user-defined-scalar-foo (ie you can tell which function was called.)
But wait, there is more!!! In order to further aid troubleshooting,
the augmented stack traces make additional information available. Each
frame in the traceback has local variables defined with more
information. You can use apsw.ext.print_augmented_traceback() to
print an exception with the local variables.
Here is a far more complex example from some virtual tables code I was writing. The BestIndex method in my code had returned an incorrect value. The augmented traceback includes local variables. I can see what was passed in to my method, what I returned and which item was erroneous. The original traceback is almost completely useless!
Original traceback:
Traceback (most recent call last):
  File "tests.py", line 1387, in testVtables
    cursor.execute(allconstraints)
TypeError: Bad constraint (#2) - it should be one of None, an integer or a tuple of an integer and a boolean
Augmented traceback with local variables:
Traceback (most recent call last):
  File "tests.py", line 1387, in testVtables
    cursor.execute(allconstraints)
                VTable =  __main__.VTable
                   cur =  <apsw.Cursor object at 0x988f30>
                     i =  10
                  self =  testVtables (__main__.APSW)
        allconstraints =  select rowid,* from foo where rowid>-1000 ....
  File "apsw.c", line 4050, in Cursor_execute.sqlite3_prepare
            Connection =  <apsw.Connection object at 0x978800>
             statement =  select rowid,* from foo where rowid>-1000 ....
  File "apsw.c", line 2681, in VirtualTable.xBestIndex
                  self =  <__main__.VTable instance at 0x98d8c0>
                  args =  (((-1, 4), (0, 32), (1, 8), (2, 4), (3, 64)), ((2, False),))
                result =  ([4, (3,), [2, False], [1], [0]], 997, u'\xea', False)
  File "apsw.c", line 2559, in VirtualTable.xBestIndex.result_constraint
               indices =  [4, (3,), [2, False], [1], [0]]
                  self =  <__main__.VTable instance at 0x98d8c0>
                result =  ([4, (3,), [2, False], [1], [0]], 997, u'\xea', False)
            constraint =  (3,)
TypeError: Bad constraint (#2) - it should be one of None, an integer or a tuple of an integer and a boolean