You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
APSW has avoided chained exceptions with VFS in the past because they didn't exist under Python 2, and because it muddies the waters. For example a VFS exception could cause SQLite to take recovery actions which could then result in further completely unrelated exceptions, so the chaining didn't make semantic sense. SQLite is also running an error code system which Python exceptions hide.
But using unraiseable also results in the exceptions being cleared after printing, so it gets more difficult to tie exceptions that happened around each other together. Doing testing of pathological error conditions has shown that chaining is the better way of handling this.
It will result in observable different behaviour in the release including this, but only when exceptions happen and even then mostly when more than one exception happens during the same SQLite call. Far more exceptions that previously came through via the unraisable mechanism will now come through directly.
Update VFS pre/post amble
Update test suite
Update vfs docs about exceptions, changing, unraisable etc
Better detection the vfs is one of ours (xAccess is currently used but could be omitted)
The text was updated successfully, but these errors were encountered:
An example of unexpected behaviour is that SQLite calls xDlOpen a second time (with slightly different parameters) if the first call returns NULL. Consequently you will the first call exception chained to the second call exception.
APSW has avoided chained exceptions with VFS in the past because they didn't exist under Python 2, and because it muddies the waters. For example a VFS exception could cause SQLite to take recovery actions which could then result in further completely unrelated exceptions, so the chaining didn't make semantic sense. SQLite is also running an error code system which Python exceptions hide.
But using unraiseable also results in the exceptions being cleared after printing, so it gets more difficult to tie exceptions that happened around each other together. Doing testing of pathological error conditions has shown that chaining is the better way of handling this.
It will result in observable different behaviour in the release including this, but only when exceptions happen and even then mostly when more than one exception happens during the same SQLite call. Far more exceptions that previously came through via the unraisable mechanism will now come through directly.
The text was updated successfully, but these errors were encountered: